libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter O'Gorman
Subject: Re: dlopening installable ltdl modules failing (OS X problem only)
Date: Sat, 18 Aug 2007 16:34:21 -0500

On Sat, 2007-08-18 at 16:29 -0400, David Fang wrote:
> > >   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.

The wrapper script for the executable itself should be setting the env
var DYLD_LIBRARY_PATH to all of the dirs with the uninstalled libraries.
otool -L will always show the final install location, so that is fine.

check that the wrapper script is in fact adding all of the required dirs
to DYLD_LIBRARY_PATH, also check dyld(1) for more potentialy useful
environment variables (DYLD_PRINT_LIBRARIES is useful).

But wait a second, talking about DYLD environment variables made me
remember the security update:
http://docs.info.apple.com/article.html?artnum=305509

Does `sudo touch /var/db/.AllowDYLDEnvironmentVariables' fix it for you?

Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]