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

[Peter O'Gorman]

On Fri, 2007-08-17 at 23:05 -0400, David Fang wrote:
> Hi,
>       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
> 
> [Yes, I'm testing the executable from outside the built lib/ directory.]
> 
> 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?)
> 
> I've tried to keep this initial report/query brief, but I can follow up
> with more concrete details if I haven't been clear enough.

Hi David,

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

Thanks,
Peter