libtool
[Top][All Lists]
Advanced

[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

Attachment: example-ltdl.sh
Description: Bourne shell script

Attachment: dlopen-in-dep-lib.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]