------- 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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
