Date: Tue, 25 Aug 1998 10:03:36 +0200 (WET) From: Andris Pavenis To: Troy VanHorn cc: djgpp AT delorie DOT com, Troy VanHorn Subject: Re: What do I need ? In-Reply-To: <199808250016.UAA24168@snoopy.UCollege.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 24 Aug 1998, Troy VanHorn wrote: > libraries built with gcc-2.8.0 with gcc-2.8.1 (warning: there will be > similar problems with upcomming egcs-1.1) > > > Andris > > > ============================================================================ > > Speaking of egcs, (or gcc for that matter), is there any chance that a > future release of gcc or egcs for djgpp will be properly configured to > produce local lables that will really be local? As it is now with gcc > 2.8.1, if I compile some C++ with exceptions enabled, the resulting object > files are really bloated, and it doesn't need to be that way. I reallize I > could probably recompile GAS to support the old method of local labels which > gcc now produces, but it would be better if the compiler itself was properly > configured. The problem really is with binutils-2.8.1: AS.EXE for DJGPP should discard symbols beginning with 'L' (local labels) and not place info in object file unless explicitly asked to keep them. Unfortunatelly current official release of binutils-2.8.1 for DJGPP expects .L for local labels and as the result info about local labels goes into object files. There were discussion about this topic some months ago. I myself am using patched version of binutils-2.8.1 that doesn't have this problem (thanks Andrew Crabtree for patch, I had to build from bnu281s.zip which was not very easy task) I think it should be fixed in DJGPP port of binutils-2.9.1 > > I've also considered writing a program which would "fix" the output of > gcc before being assembled, but I don't know if there is any way for it to > be automatically inserted between the compiler and assembly stages of > gcc.exe. > Andris