Re: Preloading without .la

[Pierre Ossman]

I guess this issue got lost somewhere. As the issue persists for me and
I'd rather not use a homebrew build environment, I'd still like this to
be resolved.

Rgds
Pierre

Pierre Ossman wrote:
> Ralf Wildenhues wrote:
>> [ Let's move this to libtool-patches
>>   Note also the list server may not come back up for a few days. ]
> 
> Major breakage?
> 
>>
>> Hi Pierre,
>>
>> Sorry for the delay.
>>
> 
> No problem.
> 
>> * Pierre Ossman wrote on Fri, Jan 27, 2006 at 05:30:22PM CET:
>>> I've put together a suggestion (against 1.5 branch, but the
>>> difference shouldn't be that big compared to HEAD) for this.
>>
>> Many thanks for your effort!  I'm not convinced yet that this is the way
>> to go, on the contrary, I have real doubts, but at least this is a start.
>>
> 
> Fair enough. Just as long as we're moving forward in some sense since
> this is an actual problem for me.
> 
>>> What it does is strip ${libext} from the name and, if we're on a
>>> $need_lib_prefix system, applies a command that should reverse the
>>> effect of $libname_spec. It then appends the '.la' extension.
>> *snip*
>>
>> OK.  But the '.la' extension should be necessary for preloading only.
>>
>>> The effect is that preloading and "normal" loading will work for any
>>> application that uses the platform independent ways of loading:
>>
>> Yep.
>>
>>> Any programs that uses lt_dlopen("module.a") will break with this
>>> patch. But I would consider such a call unsupported since they've
>>> been mucking about in libtool internals to figure out that name.
>>
>> My tests show that also lt_dlopen("module.la") may fail on some systems.
>>
> 
> Can you point me to what test you did to break this?
> 
>>> The is another breakage caused by the fact that libtool special cases
>>> the 'lib' prefix. dlpreopening a module called libfoo on a
>>> $need_lib_prefix system with a prefix of 'lib' will not work. The
>>> reason is that the above magic cannot tell the difference between
>>> 'libfoo' and 'foo' (which will be transformed to 'libfoo') on such a
>>> system.
>>
>> I'm still afraid this will cause user breakage.  You can neither expect
>> the user to use the prefix nor to omit it.  It's much too useful to be
>> able to dlopen "regular libraries", this feature is used often.
>>
> 
> Hmm... I don't really know how to solve this. The information that the
> prefix was added automatically will not always be available (we might be
> linking in a lib without a .la file).
> 
> It might be possible to be more clever by modifying the loading routines
> in libltdl. But I wanted to explore the option of just changing the
> build environment first.
> 
> What we could do is have libprefix actually be a prefix (not a command
> which can do all kinds of funky stuff). That prefix could then be built
> into libltdl so that if will try adding it when looking for the module.
> 
>>> Please review and comment. If it looks good I'll make a patch for
>>> HEAD and try to do some test cases.
>>
>> The naming is a bit inconsistent: we use `*_cmds' for `~'-separated
>> lists of commands -- yes, shrext_cmds is a bad counter example, and
>> should be fixed, too.  It should either be libname_rev, since it's
>> not a command at all, or ltmain should be able to cope with (multiple)
>> commands in there.  (This is documented in libtool.texi, too.)
>>
>> Have you tested it?  I tested something like the patch below (after the
>> forward port of your patch).  There are several ugly details to be aware
>> of: Inside the backquotes in libname_rev, you may not use double quotes.
>> This is because the config.status escaping would then lead to
>>   "`..\"..\"..`"
>> which is not portable.  Also, to use $Xsed, you should add an X,
>> and an `-e'.  ;-)
>>
> 
> Fluff ;)
> 
> The code is still a bit hackish until we have a principle that's correct.
> 
>> The patch below is missing at least documentation of `libname_rev' in
>> libtool.texi, and some decent tests, beside the cheap one.
>>
>> For me this breaks mdemo-exec.test after mdemo-static.test on GNU/Linux
>> (without any further modifications).  You can simulate need_lib_prefix
>> by help of the attached patch (which I won't apply ATM because I don't
>> know whether it's safe).  The patch creates a test which itself creates
>> a new build tree for Libtool, changes need_lib_prefix, configures mdemo,
>> (mdemo-conf, not mdemo-static), changes need_lib_prefix there, then
>> builds.  Adjust as needed.
>>
> 
> I couldn't get your attached test to work, but I did it manually and
> produced the problem. The issue is that libltdl tries to compensate for
> the added prefix, and since we now strip that things break.
> 
> So it seems the smoothest course is to modify the preload routines in
> ltdl. I see two options here:
> 
>  * Keep the preload name in the new form. Have lt_dlopen(name) try first
>    with name, then with lib_prefix + name.
> 
>  * Keep part of the new form, all but the need_lib_prefix logic. Have
>    lt_dlopen(name) try first with name, then with lib_prefix + name,
>    then with name where lib_prefix was removed.
> 
> Does this sound like an acceptable route?
>

signature.asc
Description: OpenPGP digital signature