From mint-bounce@lists.fishpool.fi Wed Jan 23 08:25:42 2008 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <479670A1.90801@freesbee.fr> Date: Tue, 22 Jan 2008 23:39:29 +0100 From: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Keith Scroggins Cc: mint Subject: Re: [MiNT] GCC 4.2.2 - Keith's Latest Progress (or lack thereof) References: <478A8F44.3030702@freesbee.fr> <47936072.4050702@freesbee.fr> <4793D6BA.9030806@freesbee.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: vincent.riviere@freesbee.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by freemint id m0N7PfKS000508 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