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("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?
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> http://lists.gnu.org/mailman/listinfo/libtool-- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
