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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
