cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1998/08/25/03:09:04

Date: Tue, 25 Aug 1998 10:03:36 +0200 (WET)
From: Andris Pavenis <pavenis AT lanet DOT lv>
To: Troy VanHorn <trvanhor AT UCollege DOT edu>
cc: djgpp AT delorie DOT com, Troy VanHorn <trvanhor AT snoopy DOT UCollege DOT edu>
Subject: Re: What do I need ?
In-Reply-To: <199808250016.UAA24168@snoopy.UCollege.edu>
Message-ID: <Pine.A32.3.91.980825095507.134624A-100000@ieva05.lanet.lv>
MIME-Version: 1.0


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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019