[Bug ld/1811] ELF linker loads member of archive for common symbol

[kean at armory dot com]

------- Additional Comments From kean at armory dot com  2005-11-05 19:03 
-------
(In reply to comment #5)
> Unfortunately it's too simple to allude to the historical handling of common
> symbols.  In a.out linkers when a common symbol appears in an object, and the
> symbol is defined in an object in an archive, then the object in the archive 
> is
> pulled into the link (actually this is somewhat target dependent--the SunOS
You sure about that?

I tries on OpenServer and UnixWare. On OSR5, I tried in both COFF and ELF
modes. In all three cases, the symbol was pulled from the object and NOT
the archive. The SunOS behaviour you described is a bit funky :)

> This last behaviour is of course pretty crazy.  But in general it isn't
> reasonable for the ELF ABI to claim that they just rely on historical 
> behaviour
> for the definition of common symbols, because in fact ELF common symbols do 
> not
> act like historical ones do.
Thats a fair comment. I guess it depends on whose view of "historical" behaviour
you take. The author of the gABI is of course a UnixWare-head, so his notion of
"historical" may be a wee bit biased. But he has been with
AT&T/USL/Novell/SCO/Caldera/SCO-again for an aweful long time, and is a mine of
historical info.

> That said, I was never all that happy with this change, and I think the
> behaviour before the change was more coherent.  But, unfortunately, given the
> way that system files and libraries are written, it is important that we be
> compatible with system linkers.  You say the UnixWare linker acts differently.
And OpenServer, for what thats worth (actually from a historical perspective,
its worth a bit becuase its a dual-ABI system supporting both SVR3.2 COFF and
SVR4 ELF).

The problem I have with teh current implementation is this. Despite what looks
like rational behaviour with H.J's test cases (I'll respond to his comment
next), I dont think the test case proves anything except that the bahviour
*looks* rational. But in terms of every day developer activities, its not.
*Especially* in the case where the symbol in teh object is the same as the
symbol in a system library. The particular case that casued me to discover this
bug was trying to compile jwhois with a version of gcc that was newly modified
to used the GNU ld (historically, on OSR5 and UnixWare, the native ld was used
which was why I never saw this problem before). jwhois legitimately wants to use
its own getopt() library, to support the GNU style long options. I now get a
link failure becuase optopt is defined in both jwhois and libc.so. It is worth
noting that libc.so is in fact a normal ar archive that has some number of
objects in it that are mean to be linked directly into the a.out, as well as a
copy of libc.so.1, which is what gets you the dynamic portion - a common trick).
The libc.so has a member opt_Data.a, which defined optopt, optind, optarg etc.
optopt is initialized to 0. In jwhois (and indeed anything that uses the GNU
getopt), optopt isn't initialized, its just declared as 'char *optopt;'. By
forcing the symbol to come from libc.so simply becuase the one in there is a
normal data symbol and the the one in getopt.o is a common is wrong. The linker
needs no other symbols from opt_data.o, and is pulling it in only because of the
common/global thing.

Extend that to more common cases where I want to, for example, override malloc
for a debugging malloc library. If any portion of malloc had a data symbol (like
a mallopt structure or some such), I would be unable to override malloc() with
my spiffy new malloc-debugging library becuase GNU ld would be pulling in the
object from the library.

The above situation is made even worse when you are using libc.a instead of
libc.so, for static links.
 
> That suggests that we need to make this target dependent.  This is precedent 
> for
> this in the a.out linker, and the use of the common_skip_ar_aymbols field in
> struct bfd_link_info.

Of course I would be happy with making this behaviour optional, becuase that
would get around my immediate problem and I can go about using GNU ld to my
heart's content. But I think that people who think they need the current
behaviour are in for some nasty surprises, as described above. I tested this on
Solaris 10, and the native link editor does in fact behave the same way the GNU
one does, but that doesn't necessarily make either one correct.

Sorry for the rambling reply :)

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=1811

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.