[Cc:ed to Mario on account of the lists.d.o mail delays] On Tue, Sep 23, 2003 at 03:27:06PM +0200, Mario Lang wrote: > Matt Kraai <kraai@alumni.cmu.edu> writes: > > > On Thu, Sep 04, 2003 at 03:50:53PM +0200, Mario Lang wrote: > >> Now, the question is what would be the proper fix for this problem. > >> > >> I do see several: > >> > >> 1. Work around this problem by patching mklibs such that it > >> detects that a certain symbol is provided by an executable. > > This is the correct solution. Executables should be able to > > provide symbols that are undefined by the libraries they link > > against. Absolutely not. Such libraries are not "libraries" at all, they're plugins; and even for plugins, this is an unnecessarily fragile design. There are all kinds of corner cases that turn up where plugins, libs, etc. don't work right if they're not self-contained at the ELF level. This mklibs problem is one; prelinking is another. Rather than spending the time to hack mklibs into accomodating such incomplete plugins with heuristics, the time should be invested in fixing the plugin architecture so that it's not a problem for the /next/ tool that expects libraries to be well-behaved. > I am only wondering, how would mklibs know that > somelib.so is loaded by this-and-that(1)? The reverse is clear, > the executable lists the libraries it requires. But how would > I know that a certain lib is going to be loaded by a certain executable? Your comments above immediately suggest one solution in particular: if it's the plugins that have the dependency on the calling executable, you can indeed reverse things with only a slight size penalty[1] by turning the present executable into a library, and turning each plugin into a program that uses that library. However, this doesn't work as well if the current program has to do some work to decide which plugin to use. The other option would be to eliminate the linker-level dependency that the plugins have on the calling executable, as I mentioned on IRC. You can do this by letting the executable call a function in the plugin which *tells* the plugin the information it needs to know about function addresses in the executable. This is minimally less efficient at runtime, but should not cause a size penalty on disk. In this case, it could be cumbersome (and unappealing to upstream) because, as you mentioned, there are some 20-30 symbols that would need to be handled this way, making for a large and possibly unwieldly function table. A third option involves using ELF-fu to make sure the undefined symbols in the plugins are weak symbols only; but I don't know how to implement this. This seems more fragile to me than the previous option, in any case. -- Steve Langasek postmodern programmer [1] in the form of a stub main() function
Attachment:
pgpsRAlLEQuWS.pgp
Description: PGP signature