[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.
(II)
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
see.
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.
regards
Peter Breitenlohner <address@hidden>
demo-1.0.0.tar.bz2
Description: Binary data