[Top][All Lists]

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

Re: libtool-1.5.20 -- lt_dlopenext fails to open preloaded module

From: Peter Breitenlohner
Subject: Re: libtool-1.5.20 -- lt_dlopenext fails to open preloaded module
Date: Wed, 16 Nov 2005 15:17:00 +0100 (CET)

On Sat, 12 Nov 2005, Ralf Wildenhues wrote:

Hi Peter,

Hi Ralf,

(I) First I have to correct a statement I made earlier.

lt_dlopenext("module"), "module" without ".la" or ".a", DOES succeed to
locate preloaded static modules, PROVIDED either LD_LIBRARY_PATH points
to the location of the .la file or lt_dlsetsearchpath() is used with a
suitable argument.

Yes, there are installed and uninstalled .la files.

My problem was that in such a situation there is no wrapper script for the
uninstalled executable and therefore LD_LIBRARY_PATH is not set
automatically (as it would be for shared libraries/modules).

It might be useful to add some words about this problem to the libtool
manual. Reading libtool.info I certainly didn't suspect that either
LD_LIBRARY_PATH or lt_dlsetsearchpath() might be needed to locate modules
statically linked into the program.


Will the demonstration be public?  :)

haven't thought about it. All that is such a hack (stupid modules and stupid
apps doing no more than "Hi, I'm here") but might be useful as demo. If you
wish I can send the tarball privately to you (R.W. + bug-libtool) but some
cleanup might be in order to make things public.

Well, if it's more than our mdemo tests, then it'd always be nice to

Meanwhile I had a look at the mdemo tests.

(A) libtool/libltdl usage

There are just a few minor and fairly trivial differences.

(1) Out of desparation I added some debug output around lt_dlopen() and
lt_dlopenext() in order to understand how they succeed or fail.

(2) I use two "loadable" modules with analogous functions (*_LTX_get,
*_LTX_set, *_LTX_str, and *_LTX_init).

(3) I declare local instead of global variables and use functions (*_get and
*_set) to access them.

Actually I didn't think about the mdemo tests (and moreover didn't have them
online on my notebook), otherwise I probably would have taken them as a
starting point.

(B) Layout of package, tests, and install-tests

My demo package contains a program that (pretends that it) can not been
tested until installed to the final location (without DESTDIR). Trying out
mechanisms for such a situation (e.g., for perl modules as part of the
package on non-linux/gnu systems) was actually the main motivation for doing
all this.

(III) A tarball demo-1.0.0.tar.bz2 is attached, for whatever it's worth.
Please fell free to use as you like, except making it publically available.

Peter Breitenlohner <address@hidden>

Attachment: demo-1.0.0.tar.bz2
Description: Binary data

reply via email to

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