bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: kean at armory dot com
Subject: [Bug ld/1811] ELF linker loads member of archive for common symbol
Date: 5 Nov 2005 04:39:26 -0000

------- Additional Comments From kean at armory dot com  2005-11-05 04:39 
-------
For the record, I will repost a private mail I had with H.J about this.

=========
Ok I've spent a while staring at that code and thinking about
this, and even though you say it is there on purpose, I believe
it is wrong. Here's why.

It is expected behaviour to be able to over-ride variables and
objects that appear in libraries, whether shared or archive
makes no difference. For example, libraries like dmalloc
depend on that behaviour. In this case, so do a lot of GNU
programs. Even though libc may provide getopt, the program
wants to provide its own getopt, especially for long option
handling.

An explicitly named object should always take precedence over
an object in a library. The only reason that is *not* happening
here is becuase GNU getopt declares optarg as:
  char *optarg;
thus making it a common symbol. If I was to change that to
  char *optarg = 0;
then it becomes a normal data symbol and it will be used
in preference to the one in the library, which is exactly
the intended behaviour. The only reason the link editor has
to pull in teh object from the archive is if it provides some
*other* symbol that the program needs, and in that case you
would legitimately get a warning that the same symbol is
defined in two places. However, simply rejecting the explicitly
named object in favour of the object in the archive just becuase
the explicit object didn't initialize the variable breaks a
very fundamental UNIX paradigm.
========

I read the mail thread pointed to in #2, and Ian asked what SVR4/UnixWare
do. UnixWare treats it as I describe above. In fact the current GNU ld
is broken on that platform because of this. I spoke to the author of the
gABI and he maintains the Solaris linker is broken, and the UnixWare one
is correct. With no prompting he cited almost the exact same reasons I
outlined above. The problem is the gABI doesnt specify semantic interprtation
of COMMON symbols. In the gABI authors words, that was because the behaviour
was "older than ELF itself" and simply the way archives were meant to be
handled.

-- 


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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]