[Top][All Lists]

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

Re: removal of .la files from Debian and a possible solution to the libt

From: Ralf Wildenhues
Subject: Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Date: Wed, 26 Aug 2009 22:26:35 +0200
User-agent: Mutt/1.5.20 (2009-08-09)

* 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 c.c -Wl,-soname,
ln -s
cd ..
echo 'extern int c (); int a () { return c (); }' > a.c
gcc -shared -fPIC -o a.c -Wl,-soname, -Lc -lcee \
ln -s
cd ../b
echo 'extern int a (); int b () { return a (); }' > b.c
gcc -shared -fPIC -o 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("", RTLD_LAZY);
    if (!handle) {
        fprintf(stderr, "%s\n", dlerror());

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

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

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

    printf("%d\n", (*p)());
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
in the line creating  Nice.

> So when enchant dlopens, the dependency on
> and in turn its dependency on 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 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.


reply via email to

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