[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: libtool, -rpath into libs
From:       Michael Matz <matz () ifh ! de>
Date:       2000-04-10 23:50:39
[Download RAW message or body]

Hi,

On Tue, 11 Apr 2000, David Faure wrote:
> > I want to build the modules (essentialy shared libs, like kio_xxx.so) with
> > hardcoded paths to shared libs they depend on.
> 
> You mean, when using LIBADD ?

Yes... in LIBADD I have my -L and -l options, and in LDFLAGS the relevant
-rpath options.

> Doesn't it store the full path ?

No -L does not store any path in the executable (or shared module).

> All the dlopening stuff seems to find the associated libs fine for me,
> even without the KDE lib directory in ld.so.conf ...

Hmm, that may be because most dlopen'ing takes place in executables where
LD_LIBRARY_PATH is set to the right place (do you set it in
$HOME/.blarc?). E.g. if kdeinit is started with correct LD_LIBRARY_PATH
the dlopen() there should take that into account. The problem I have,
is, that I have to link against libraries not in KDEDIR/lib. I could set
LD_LIBRARY_PATH for kdeinit (and further assure that other binaries are
not trying to dlopen()'ing anything which needs other paths), but that
would be suboptimal, as at least ELF has the nice mechanism of hardcoding
searchdirs to shared libs into the shared module. I want to use that.

> > If nobody has any idea, I guess I have to beat on libtool a little bit.
> 
> Sure something is needed here ?

Yes. I just tested kio_ldap with shared ldap libs in /opt/ldap/lib,
/opt/ldap/lib _not_ in ld.so.conf,not in LD_LIBRARY_PATH and not
hardcoded. It does not work (meaning it links with the warning, but
does not get dlopen()'ed or exec()'ed). Not very surprising ;)

Whereas if I link and install by hand (with -Wl,--rpath and friends) the
module gets dlopen()'ed and works.


Ciao,
Michael.

[prev in list] [next in list] [prev in thread] [next in thread]