This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New ELF linker code added to GNU binutils


"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Tue, 25 Mar 2008, Ian Lance Taylor wrote:
>
>> I think a separate version for gold makes sense during this
>> development period.  In the future it may make sense to simply fold it
>> into the usual GNU binutils version number.  I'd be happy to hear
>> other opinions.
>
> There are various configure tests out there (in GCC (more than one such 
> test) and glibc at least, maybe elsewhere) that parse ld --version output 
> and try to decode a version number from it.  (The GNU Coding Standards say 
> they can just take the number after the last space on the first line of 
> --version output, but various past ld versions aren't compatible with 
> that.)  These tests could easily get confused with anything too different 
> From the present output (and I'd rather they didn't grow yet more cases, 
> but instead moved towards just taking the last word from the first line).  
> Now, if gold isn't ready to build glibc (or otherwise is missing a feature 
> decided by a version test) then maybe you'd consider it a feature if glibc 
> decides it's ld version 1.4 and so refuses to build with it....

gold is ready and able to build glibc.  But obviously gold is not the
same as GNU ld--it depends on what the test is looking for.  A version
test of GNU ld can be misleading with respect to gold.  Fortunately
many tests look at the --help output.  Those tests should return the
right result.

The glibc configure test does look at --version, but I believe it
winds up picking up the GNU binutils version which gold reports.

The gcc configure test is smarter in that it does pick up the right
version number.  It also separately picks up the date, for which it
will get the GNU binutils date if there is one.  I think that when the
GNU binutils version has a date, as it does when not doing a release,
gcc will decide everything correctly.  When it doesn't, I think gcc
will wrongly decide that the linker doesn't support hidden symbols or
comdat groups, and will thus set HAVE_GAS_HIDDEN and HAVE_COMDAT_GROUP
incorrectly.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]