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

Bug#211092: [vorlon@netexpress.net: Re: mklibs and brltty]



Information from mailinglist:
----- Forwarded message from Steve Langasek <vorlon@netexpress.net> -----

Date: Thu, 25 Sep 2003 14:50:38 -0500
From: Steve Langasek <vorlon@netexpress.net>
To: Mario Lang <mlang@debian.org>
Cc: debian-boot@lists.debian.org
Subject: Re: mklibs and brltty
In-Reply-To: <[🔎] 871xu7fxed.fsf@lexx.delysid.org>
List-Id: <debian-boot.lists.debian.org>
Resent-Sender: debian-boot-request@lists.debian.org
Resent-Date: Fri, 26 Sep 2003 18:59:25 -0500 (CDT)

[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



----- End forwarded message -----



Reply to: