[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dlopening installable ltdl modules failing (OS X problem only)
From: |
David Fang |
Subject: |
Re: dlopening installable ltdl modules failing (OS X problem only) |
Date: |
Sun, 19 Aug 2007 00:27:47 -0400 (EDT) |
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
Re: dlopening installable ltdl modules failing (OS X problem only), Ralf Wildenhues, 2007/08/18
- Re: dlopening installable ltdl modules failing (OS X problem only),
David Fang <=