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

[Ralf Wildenhues]

Hi Peter,

* Peter Breitenlohner wrote on Wed, Nov 16, 2005 at 03:17:00PM CET:
> 
> (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.

> 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).

Ahh, ok.

> 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.

It might be even more useful to fix this bug!  libltdl should not _need_
the .la file at all, neither the .a file.

We have an entry for this on our online TODO list:
http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap

If you feel adventurous to work on a fix, be our guest!  ;-)

> (II)
> 
> 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.

OK.

> (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.

Ah, good idea to do 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.

I've not yet had a chance to take a detailed look, but might ask back
some time later.  In case we find useful stuff, would you mind parts
ending up in a testsuite test?

Cheers,
Ralf