Re: [MiNT] GCC 4.2.2 - Keith's Latest Progress (or lack thereof)

[Vincent Rivière <vincent.riviere@freesbee.fr>]

Keith Scroggins a écrit :
> The new Binutils worked for me for that test, and the resulting 
> excutable was much smaller (around 60% to 65% of the size of the previous).

Excellent !

A note about the file sizes:
> -rwxrwxrwx    1 root     root      1685621 Jan 22 15:58 hello.tos
> -rwxrwxrwx    1 root     root      2964211 Jan 22 12:24 hello.tos-old

In my earlier patches for binutils 2.18, there was a bug when an 
executable was linked with --traditional-format. There was a big 
harmless garbage after the normal end of the executable (actually, some 
parts of GNU symbols). I fixed that bug in binutils-2.18-mint-20070923. 
The ld you used for linking hello.tos-old suffered of that bug.

In the current ld, when an executable is linked with 
--traditional-format, the DRI symbol table includes the local labels 
beginning with ".". It is not the standard behavior, however it makes 
debugging a little easier. So there is a lot of DRI symbols, causing the 
executable to be huge.

If I link the program with "-s" (for stripping the symbols), I get an 
executable of 395515 bytes. I is still huge for an Atari ST executable, 
especially for a simple "Hello, World !". All that code come from 
MiNTLib, libstdc++, libsupc++ and libgcc.

The classic rule for linking objects is: if an unresolved symbol is 
found in a .o, all the contents of that .o will be linked into the final 
executable. Thus, if all the methods of a C++ class are implemented in 
the same cpp file (which is usually the case), if a method needs to be 
linked, all the methods will be linked ! The unused methods will then 
generate undefined symbols, which have to be found in other .o, and so 
on... Finally, nearly everything gets linked into the executable... 
which is fat, but containing useless code. GCC/ld can link only the 
necessary functions (and not whole .o), but only when using .o in ELF 
file format. Unfortunately we must use .o files in a.out format, because 
 it is the only format usable by our patched linker (today !).

> So, g++ is working natively!!  I will test some more items (my tools I 
> had been using, and then move into ScummVM if successful) and let you 
> know how it does.
>
> I don't know if there is much point in sharing the native GCC 4.2.2 
> build yet?  Its a 15 meg tgz right now.

Share it !
If the binaries are available, a lot of more people will try the new 
GCC, they will fix the sources of their programs for it, they will find 
more bugs, we will fix them, and we will have a better compiler for 
making better software !

The best form for binary distribution (even for testing) would be a RPM 
package. However I don't know (yet) how to build them.

Great work !

--
Vincent Rivière