[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Breitenlohner
Subject: Re: libtool-1.5.20 -- lt_dlopenext fails to open preloaded module
Date: Thu, 10 Nov 2005 13:34:04 +0100 (CET)

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
and only
did succeed.

I believe
would succeed as well.
/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.

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

Peter Breitenlohner <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]