Recently I hacked together a small package in order to demonstrate how
libtool works (using autoconf-2.95, automake-1.9.6, and libtool-1.5.20).
I did all this on a linux-gnu system perfectly capable to dlopen modules,
but prevented that to happen by configuring with "--disable-shared".
In order to compensate for that, I added this
app1_LDFLAGS = -export-dynamic \
-dlopen ../modules/mod1.la \
-dlopen ../modules/mod2.la -L$(moddir)
to the Makefile.am responsible for building a test program "app1" that was
supposed to dlopen the (installed or uninstalled) modules "mod1" and "mod2".
The test program failed with both
lt_dlopenext("mod1")
or
lt_dlopenext("mod1.a")
and only
lt_dlopen("mod1.a")
did succeed.
Looking at the code it was clear why lt_dlopenext failed in this case (but
succeeded with "--enable-shared"). Since neither "mod1" nor "mod1.a" has one
of the extensions ".la" or ".so", lt_dlopenext tried to append them. But in
the situation described, there is only "mod1.a" built into the test program
(no "mod1.so" and no "mod1.la").
If I correctly understand the rationale for lt_dlopenext, the purpose is
precisely to hide such details from the user.
Looking at the code I saw no easy fix for the above problem. Maybe the best
strategy would be that "presym_open()" changes the extension of the FILENAME
given to it from ".la" to ".a". That way lt_dlopen("mod1.la") would equally
succeed to locate the preopened module "mod1.a" -- probably in the spirit of
libtool/libltdl.
regards
Peter Breitenlohner <[EMAIL PROTECTED]>
_______________________________________________
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
