Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem

[Ralf Wildenhues]

* Anssi Hannula wrote on Wed, Aug 26, 2009 at 12:05:22PM CEST:
> Ralf Wildenhues wrote:
> > * Bob Friesenhahn wrote on Wed, Aug 26, 2009 at 05:01:18AM CEST:
> >> Is someone here willing to contribute a portable m4 macro which
> >> tests the compiler (and/or linker) to prove beyond a shadow of a
> >> doubt that it adequately supports the implicit linkage required? The
> >> tests should work for more than Linux and should be based on
> >> observed behavior.
> > 
> > Is support in Debian full now?
> 
> I'm not sure what you mean by this.

Well, my message certainly was terse; what I meant was whether the
following scenario now works:

> > Do dlopen'ed modules that have indirect
> > dependencies outside of default-searched library paths get loaded
> > correctly now, with DT_RPATH entries only pointing to direct deplibs
> > (and recursively for their DT_RPATH entries)?
> 
> This works fine without linking in dependency_libs. I continue the test
> from my earlier message:

What I would like to see is this test (written without using libtool,
sorry, I haven't gone through your test):

cd /tmp
mkdir a a/c b main
cd a/c
echo 'int c () { return 0; }' > c.c
gcc -shared -fPIC -o libcee.so.0 c.c -Wl,-soname,libcee.so.0
ln -s libcee.so.0 libcee.so
cd ..
echo 'extern int c (); int a () { return c (); }' > a.c
gcc -shared -fPIC -o liba.so.0 a.c -Wl,-soname,liba.so.0 -Lc -lcee \
        -Wl,-rpath,c
ln -s liba.so.0 liba.so
cd ../b
echo 'extern int a (); int b () { return a (); }' > b.c
gcc -shared -fPIC -o b.so b.c -Wl,-rpath,../a -L../a -la
cd ../main
cat >main.c <<\EOF
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

int main ()
{
    void *handle;
    int (*p)(void);
    char *error;

    handle = dlopen("b.so", RTLD_LAZY);
    if (!handle) {
        fprintf(stderr, "%s\n", dlerror());
        exit(EXIT_FAILURE);
    }

    dlerror();    /* Clear any existing error */

    *(void **) (&p) = dlsym(handle, "b");

    if ((error = dlerror()) != NULL)  {
        fprintf(stderr, "%s\n", error);
        exit(EXIT_FAILURE);
    }

    printf("%d\n", (*p)());
    dlclose(handle);
    exit(EXIT_SUCCESS);
}
EOF
gcc -o main main.c -ldl
LD_LIBRARY_PATH=../b ./main


And trying that out now, I see that while this doesn't work, it works as
soon as you replace
  -Wl,-rpath,c
with
  -Wl,-rpath,`pwd`/c
in the line creating liba.so.0.  Nice.

> So when enchant dlopens libenchant_voikko.so, the dependency on
> libvoikko.so.1 and in turn its dependency on libmalaga.so.7 in another
> directory are resolved fine.

Yep; seems your test was similar.

> >> Support for indirect dependencies should be a configure option so
> >> that it should be specifically requested.
> > 
> > See $link_all_deplibs (which is "no" on Debian but "yes" in FSF
> > Libtool).
> 
> IIRC link_all_deplibs only affects executables, not libraries.
> 
> The comment describing link_all_deplibs seems to agree:
> # Whether libtool must link a program against all its dependency libraries.

The code in ltmain.sh doesn't agree, however.  And IIUC then Debian
wouldn't want libraries to link against their indirect deplibs either,
as that would still make the problem set too big for them.

Cheers,
Ralf