[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bad -static and -dlopen interaction.
From: |
Peter Rosin |
Subject: |
Re: Bad -static and -dlopen interaction. |
Date: |
Thu, 6 Sep 2007 11:40:55 +0200 |
User-agent: |
Mutt/1.5.12-2006-07-14 |
On Tue, Sep 04, 2007 at 12:03:15AM +0200, Peter Rosin wrote:
> Hi!
>
> I am fooling around with the -dlopen option, trying to
> fix some issues with a library that has a bunch of plugin
> modules.
Ok, I redid the example using ltdl (attached), and it doesn't make
the problems go away.
The problems that I have identified (so far) are:
(1) When libfoo.la is built, it includes a generated source file
libfooS.c in the library. The file has this content (and some
boilerplate):
lt_dlsymlist
lt_libfoo_LTX_preloaded_symbols[] =
{ { "libfoo", (void *) 0 },
{0, (void *) 0}
};
I find it strange that the symbols from the -dlopened modules
are not listed.
(2) Even if the symbols from the modules were listed, it would not
help, due to the link order. When the static apps are linked,
the link order is
.../module1.a .../libdep.a .../module2.a .../libfoo.a
Since libfooS.o is part of libfoo.a, adding symbols from the
modules there will not trigger anything since module1.a and
module2.a are already processed. In fact, simply adding the
syms to libfooS.c would break the link with undefined symbols.
If (1) is fixed, the libs would also need to be reordered,
or dup of libfoo.a added before module1.a.
(3) When the static variants of the bar app are linked, libtool does
not pick up the fact that libfoo.la -dlopens modules. At least
not 100%, and does therefore not add any bar-staticS.o (or
bar-all-staticS.o etc) to the link, thus the -dlopened modules
are not preopened (unless I add -dlopen self when linking static
apps, that triggers the inclusion of bar-staticS.o). I have
attached a fix for that, but I really think that (1) and (2)
above should be fixed instead, that would make this problem go
away, I think.
(4) When extracting symbols from modules (e.g. module1.la), libtool
also adds symbols from the dependencies (libdep in this case).
Unfortunately, when using the -static option, it extracts symbols
from the static version of non-local dependencies even if it is
later linking with the shared version of those dependencies.
On my platform, the link fails when all symbols available in the
static version of the dependencies are not available in the
shared version (the "helper" symbols in this case). I have no
workaround for that, -static is simply not a usable option in this
scenario.
Cheers,
Peter
example-ltdl.sh
Description: Bourne shell script
dlopen-in-dep-lib.patch
Description: Text document