Subject: Re: RFC: migration to a fully dynamically linked system
To: Bill Studenmund <wrstuden@netbsd.org>
From: John Nemeth <jnemeth@victoria.tc.ca>
List: tech-userlevel
Date: 01/09/2002 17:48:26
On Apr 21, 2:21am, Bill Studenmund wrote:
} 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.
Couldn't this be fixed by requiring programs that want to use
dlopen() to have an appropriate symbol table (perhaps with some
tweaking of the tools)? Although, I do see a potential problem that
the symbols might be the same, but they might not refer to the same
kind of object (i.e. an expanded structure in a newer version of a
library that is being linked dynamically). Another potential issue I
see is dynamic libraries using libc functions that the main program
doesn't. This would require pulling in a dynamic libc.
} 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
I'm not going to argue for or against it since I don't have enough
information and I think it would be futile anyways. I'm just
questioning whether we really need to follow the aspect of the ELF spec
that says that a static program can't call dlopen(). I.e. is there
some way we can get around this?
}-- End of excerpt from Bill Studenmund