Re: dlopening installable ltdl modules failing (OS X problem only)

[David Fang]

Hi,
        Must've missed this message earlier...

> > The executable takes command-line arguments that call lt_dladdsearchpath
> > (option -L) and lt_dlopenext (option -l).  The file, ../../lib/mymodule.la
> > has already been built at the time of testing.  The executable is invoked
> > with "-L../../lib -lmymodule" to reference ../../lib/mymodule.la.
>
> At link time, use in LDADD/LIBADD
>   ../../lib/mymodule.la
>
> instead of
>   -L../../lib -lmymodule

        Sorry if I confused you, to clarify: "-L../../lib -lmymodule" were
flags passed to the test executable at *run-time*, and have nothing to do
with the building or linking.  The executable is mimicking a ld-like
options for demonstration purposes.

> for deplibs (as a rule of thumb you should never use -l for in-tree
> libs).  For modules that you don't actually link against, but only
> lt_dlopen, use
>   -dlopen ../../lib/mymodule.la

        The test executable can potentially open any arbitrary module, and
none are dlopened by default, so passing -dlopen to all possible test
libraries doesn't seem appropriate.  And I'm not doing any pre-opening in
this case.

> (typically this causes no changes in the link, unless you also support
> dlpreopening), and at execution time of uninstalled programs, use
>   ./libtool --mode=execute -dlopen ../../lib/mymodule.la $program
> which should help to find the needed libs.

        This would kind of cheat the tests I've set up: I wanted the
program itself to do the dlopening via its own interface (command-line
options in the demo, also interpreter commands).

> But maybe I've not yet understood the root cause of the problem, and
> it's Darwin specific, in which case Peter will find out.  ;-)

With the demo at:
http://www.csl.cornell.edu/~fang/sw/ltdl_test-0.0.1.tar.bz2

I've shown (I think) that one correct solution is to pass additional paths
to uninstalled deplibs of modules (their .libs/) through
[DY]LD_LIBARARY_PATH at run-time during testing (make check).
dlopening an uninstalled module *without* deplibs has no problems.
Problem is only exhibited on darwin{7,8} of the platforms I've tested.

        I'm stlll curious why the tests that fail on darwin actually
*work* on linux and freebsd...  After digging through more of
libtool/ltdl's internals, I'm still a bit puzzled how those systems
magically found an uninstalled module's uninstalled dependent libraries
during make check testing, @emph{without any additional assistance from
search paths}.  (Wherein lies the magic?)

Fang