On Fri, 4 Jan 2002, John Nemeth wrote:

>      I thought NetBSD was about doing the "right" thing first, and
> following specs second.  I realise that certain specs are needed for
> interoperability such as POSIX and TCP/IP, however ELF doesn't fall in
> that category.  I do realise that using something like ELF gives the
> ability to use precanned tools such as GCC, GDB, Binutils, etc. instead
> of having to roll our own, as well as making it easier to handle
> binaries from other OSes.  However, is there any reason that we need to
> adhere to this particular aspect of the ELF spec?  So far, the only
> objection I have seen is the problem with conflicts between dynamic
> symbols and static symbols.  Is this really a showstopper?  Is there
> any other technical reason (following specs is a political reason) that
> it can't be done?

I'll let the folks quite familiar with this aspect of the problem answer
some of the pointed details. But the "conflict" between dynamic & static
symbols is, as I understand it, a show stopper. The problem is that it's
not a duplicate symbol, but that there are two different ones. The static
binary won't, by default, retain the symbolic names for the variables it
has in its globals, so there's no way to tie the static & dynamic ones
together. The static code will be using one version, and the dynamic code
another.

Oh, I don't think that's specific to ELF.

Also, (playing the devil's advocate for a minute) are we sure that ELF
isn't "right"? :-) NetBSD does try to do the "right" thing. From all I've
seen about linking formats, ELF is rather sane. It could be that there
wouldn't be much difference between a static program which can dynamically
load modules (however we would get there) and a dynamically linked one, so
it's easier to just do dynamic.

Take care,

Bill