libtool-1.5.20 -- lt_dlopenext fails to open preloaded module

[Peter Breitenlohner]

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 <address@hidden>