GCC Working Configurations Table

[AJ]

Hi,

I mentioned last week on the wiki, that the GCC Working Configurations table had become a little big for sensible resolutions What doesn't help is that the current GCC version is always on the far right of the table and therefore is not visible (4:3 @ 1024x768).

A few of us have been discussing this and I have created an alternative table which displays higher version numbers on the right and splits out versions of GCC below v4.0.0.

The two articles in question are:
GCC Cross-Compiler and
user:AJ/GCC Cross-Compiler

Because the article is used so often and by so many people, I just wanted to get opinions from the forums before I actually merge my changes. Any thoughts?

Cheers,
Adam

[xenos]

Alternatively, you could transpose the table, i.e. exchange rows and columns, with binutils versions decreasing from left to right and gcc versions decreasing from top to bottom. That could make it easier to scroll through the table.

[Solar]

...or we could scrap the table altogether. The last proven incompatibilities were from GCC 3.3 times (or from people who can't handle version numbering despite explicit warnings, and I doubt any text or table could solve that particular problem). I doubt there's much information to be won from the table.

[Creature]

Alternatively, you could transpose the table, i.e. exchange rows and columns, with binutils versions decreasing from left to right and gcc versions decreasing from top to bottom. That could make it easier to scroll through the table.

If the table is to stay as it were, I suggest you also place the binutils versions in decreasing order (otherwise you have GCC with decreasing version numbers and binutils with increasing version numbers, which seems a bit strange to me).

Swapping the versions around might help, since it would make the table a vertical monstrosity instead of a horizontal one. I'm not sure if it won't be too big then, however. But if we were to do this, I don't see any use of splitting GCC3 and GCC4 versions in separate tables.

...or we could scrap the table altogether. The last proven incompatibilities were from GCC 3.3 times (or from people who can't handle version numbering despite explicit warnings, and I doubt any text or table could solve that particular problem). I doubt there's much information to be won from the table.

I've thought of this as well, since there are a lot of question marks in this table and the only few that have been tested have passed anyway. Maybe we could make a small list (but not a table) of versions that don't work well together instead of a huge table of what does, seeing as there is a minority of non-working combinations.

[AJ]

If the table is to stay as it were, I suggest you also place the binutils versions in decreasing order (otherwise you have GCC with decreasing version numbers and binutils with increasing version numbers, which seems a bit strange to me).

I hoped to do that, but won't bother unless the question mark over the table's future goes away

...or we could scrap the table altogether.

NP with that, although it is useful for answering those "didn't follow the tutorial..."-type questions. It's quite nice to know that a particular version combination has been shown to work. As a compromise, how about taking Createure's suggestion (mention versions that do not work and in addition, simply have "Latest known working version: GCC 4.4.3 / Binutils 2.20" somewhere obvious on the page, that just gets updated in the same way as the table currently does. I'm happy to just keep the current table in my namespace for sentimetalities' sake

We currently have i[5/6/x]86-elf and x86_64-elf articles separately on the wiki. This was useful when x86_64 needed patching, but since 4.3.x, this hasn't been necessary. Therefore, scrap the x86_64 article and perhaps also list known good TARGET strings.

Cheers,
Adam

[Solar]

...or we could scrap the table altogether.

NP with that, although it is useful for answering those "didn't follow the tutorial..."-type questions. It's quite nice to know that a particular version combination has been shown to work.

Good point. Perhaps keep the table on the discussion page (for reference by those who are facing those "tutorial doesn't work" questions)?

As a compromise, how about taking Createure's suggestion (mention versions that do not work and in addition, simply have "Latest known working version: GCC 4.4.3 / Binutils 2.20" somewhere obvious on the page, that just gets updated in the same way as the table currently does.

Table on discussion page, latest known-good version in the article?

(I would suggest, though, that only versions actually available on ftp.gnu.org be taken into account.)

[AJ]

(I would suggest, though, that only versions actually available on ftp.gnu.org be taken into account.)

I saw your comment on the discussion page - just so no-one gets the wrong idea, version 4.5.0 wasn't me!

[Solar]

just so no-one gets the wrong idea, version 4.5.0 wasn't me!

It was bluechill, who had troubles on MacOS and had to patch GCC trunk. (Wiki history is a fine thing. )

[Brynet-Inc]

Maybe only the major/minor number should be mentioned? gcc 4.5.x or 4.4.x or 4.2.x? perhaps with notes below the table mentioning issues with specific "sub" releases in that series?

[Combuster]

I agree with Solar that moving the compatibility list would be a good option. I would however put it on a separate page, and not someplace unofficial as the talkpage...

[AJ]

Hi,

Taking on board the suggestions here, I'm going to start work.

I will remove the table from the GCC Cross-Compiler article as mentioned and have started work reversing the version numbers here:user:AJ/GCC Cross-Compiler. Once I'm happy with it, I'll move that page out of my namespace to somewhere sensible, with links to/from the GCC Cross-Compiler article. I'll also add a "latest tested" bit in the main article.

Cheers,
Adam

[edit: initial changes to the article complete - needs reviewing and proof-reading]