bug-libtool
[Top][All Lists]
Advanced

[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: Ralf Wildenhues
Subject: Re: libtool-1.5.20 -- lt_dlopenext fails to open preloaded module
Date: Wed, 9 Nov 2005 22:48:54 +0100
User-agent: Mutt/1.5.9i

Hi Peter,

* 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?  :)

> 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.

> 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.

Yes, certainly.

> 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.

Yes.

Note these are not the only issues still to be addresses with preloaded
modules.  I would love to look at them, but must confess that, at the
moment, it's important to get both 1.5.22 and the next 2.0 alpha release
out the door soon.  Above issues are not regressions, so unless someone
else comes up with patches, they'll have to wait a little bit.  I've
added them to the TODO list.

In any case, thank you for reporting this.

Cheers,
Ralf




reply via email to

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