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