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