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

[David Fang]

> >     I'm having a problem testing some libtool (ltdl) modules, but only
> > on OS X (darwin7 and darwin8, libtool 1.5.22 and .24).  My executable
> > lt_dlopens a .la library in another built directory (during make check
> > testing), and fails with an lt_dlerror message like:
> >
> > dlopen(../../lib/mymodule.0.so, 9): image not found
> >
> > 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.
> >
> > in $(srcdir)/../../lib/Makefile.am:
> > pkglib_LTLIBRARIES = mymodule.la
> > mymodule_la_LIBADD = (dependent libs)
> > mymodule_la_LDFLAGS = -module
> >
> > The reason for failure comes to mind: mymodule.la is a plug-in that will
> > eventually be installed in $(pkglibdir).  At build-time, before
> > installation, the actual shared objects lie in ../../lib/.libs, and not in
> > ../../lib.  However, on the other systems I've been testing (suse-linux,
> > freebsd6.2, with ltdl from libtool-1.5.24), the very same tests are able
> > to find the actual shared objects with lt_dlopenext, when passing only
> > paths to the .la files.  On these systems, lt_dlopenext must have searched
> > in .libs (relative subdir), however, it seems that on Darwin, the search
> > process didn't look in .libs for the images.
> >
> > My questions:
> > Is the above test supposed to work, as I've observed on linux/freebsd?
> >     (or is that purely accidental?)
> > If so, is there a reason why the same should not work on Darwin?
> >     (or have I found a possible bug?)
>
> It is entirely possible that you've found a bug, Mac OS X should work
> the same as linux et.al. in this regard. Does the module itself have any
> dependencies that possibly are not being found (check with otool -L
> mymodule.0.so)? If that is not the case, please send more info (if you
> like you can send me the project offline and I'll look into it).

Yes, the mymodule.la does have a dependent library, also built.  (otool -L
../../libs/.libs/mymodule.0.so confirms that the dependent library is
being referenced in the final installed location via absolute path, where
it does not yet exist.)  In fact, if I make another test module *without*
any additional LIBADD dependencies in the same place as mymodule.la, the
executable is able to lt_dlopen it without errors. So the lt_dlerror
message from before is misleading; it's probably finding the first library
fine, just not its dependency, and reporting an error on the first
library.

Are we getting warmer?  (If I have to send along the project, I'll have to
whittle down the test case -- you *don't* want to spend all day compiling
this monster, and its package dependencies.  :D )

Fang