X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Message-ID: <4A1CC51F.70601@iki.fi> Date: Wed, 27 May 2009 07:44:15 +0300 From: Andris Pavenis User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: Re: possible BinUtils 2.17+ bug (a.out is stubbed, didn't use to be) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com Rugxulo kirjoitti: > Hey guys, > Recently it was discovered by CWS and myself that "gcc myfile.c -o > myfile" produces myfile, myfile.exe as usual. And yet, BinUtils 2.16.1 > doesn't seem to stub the "myfile" object (with the .EXE header) but > later BinUtils do. Isn't this a bug? I tried swapping out DJGPP 2.04 > with 2.03p2 to see if it was STUBIFY, but nope, seems to (most likely) > be a bug in latest BinUtils 2.17 or newer (2.16.1 didn't have this > problem although DJGPP ELF's 2.16 does, oddly). > > Just FYI in case anyone stumbles upon this or knows a quick fix. I suspect the reason is linker scripts. Sometimes ago GCC provided it's own linker script which caused binutils not to add stub (search file djgpp-x.djl in GCC package, such file djgpp.djl is also provided in djdev20X packages for really old GCC versions. Some time in the past linker script did not any more provided in GCC packages (it does not logically belong to GCC, but to binutils). As result the output format coff-go32-exe from binutils default linker script were used instead of coff-go32. I guess the reason was trying to add stub automatically from linker. In that case there would be no need to invoke stubify from GCC. However in that case without invoking stubify from 'gcc myfile.c -o myfile' one woul get only file myfile but not myfile.exe. It would break things in cases when also myfile.exe is expected to be generated. I cannot immediately say whether changing binutils default output format to coff-go32 would not break anything. You can try to: 1) take the default linker script from binutils ($DJDIR/lib/ldscripts/i386go32.x) 2) copy it to the directory where myfile.c (or which file You are compiling) is located with different name (eg. i386go32.djl) 3) change output format in i386go32.djl to coff-go32 4) specify linker script with GCC option -T: gcc myfile.c -Ti386go32.djl -o myfile Andris PS. As far as I remember files in $DJDIR/lib/ldscripts are there for reference only and not used by ld.exe, so there is no use from modifying them in place. PS2. I did try any of this practically now as I'm writing this message under Linux.