[Top][All Lists]

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

Re: Preloading without .la

From: Pierre Ossman
Subject: Re: Preloading without .la
Date: Tue, 22 Aug 2006 16:20:01 +0200
User-agent: Thunderbird (X11/20060808)

Another reminder...

Pierre Ossman wrote:
> 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("") 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?
> ------------------------------------------------------------------------
> _______________________________________________

Pierre Ossman            OpenSource-based Thin Client Technology
System Developer         Telephone: +46-13-21 46 00
Cendio AB                Web:

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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