Re: libtool-1.5.20 -- lt_dlopenext fails to open preloaded module

[Peter Breitenlohner]

On Wed, 9 Nov 2005, Ralf Wildenhues wrote:

> * Peter Breitenlohner wrote on Mon, Nov 07, 2005 at 06:35:43PM CET:
> > 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).
>
> Will the demonstration be public?  :)

Hi Ralf,

haven't thought about it. All that is such a hack (stupid modules and stupid
apps doing no more than "Hi, I'm here") but might be useful as demo. If you
wish I can send the tarball privately to you (R.W. + bug-libtool) but some
cleanup might be in order to make things public.

> > 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.
>
> I believe
>  lt_dlopen("mod1.la")
> would succeed as well.
>  lt_dlopenext("mod1")
> /should/ succeed, but currently doesn't, as you noted.
> In fact, it should not need any on-disk files for this.
> This is a known issue with preloaded modules.

NO.
  lt_dlopen("mod1.la")        <= (1)
and
  lt_dlopenext("mod1")  <= (2)
both fail. Actually (2) fails because (1) fails, since (2) just first tries
(1) and then
  lt_dlopen("mod1.so")

regards
Peter Breitenlohner <address@hidden>