libtool
[Top][All Lists]
Advanced

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

Re: Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_d


From: Gary V. Vaughan
Subject: Re: Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_dlsearch_path_spec)
Date: Tue, 9 Dec 2014 11:53:22 +0000

[remembered to remove Orion from the Cc: list this time as requested]

Hi Pavel,

> On 9 Dec 2014, at 08:14, Pavel Raiskup <address@hidden> wrote:
> 
>> On Monday 08 of December 2014 15:55:22 Gary V. Vaughan wrote:
>> [..]
>>  LT_SYS_LIBRARY_PATH
>> [..]
> 
> That LT_SYS_LIBRARY_PATH concept sounds good, thanks!
> 
>>>> * should I use AC_ARG_VAR rather?
>> 
>> I'm not entirely clear yet exactly when the extra directories are
>> important...
>> 
>> It seems not that useful for it to be only at configure time, since we
>> also want our installed libtool to honor changes in the environment.  Or
>> do we bake the configure time setting into the installed and client
>> project generated libtool always?
>> 
>> If at configure time only, AC_ARG_VAR is sensible, but at libtool time
>> seems more flexible, at the expense of being centralised in config.site.
>> 
>> WDYT?
> 
> That makes sense.  Ideally, we could make the variable ./configure time
> sensitive and also sensitive to environment.  Something like
> : ${LT_SYS_LIBRARY_PATH="/configure/time/detected/LT_SYS_LIBRARY_PATH"}?

Great. The only wrinkle I can see here is that we need the function for
injecting lt_cv_sys_dlsearch_path into the dangling colon in the runtime
LT_SYS_LIBRARY_PATH shared between libtool.m4 and ltmain.in. I haven't
double checked, but I'm certain we have functions that are shared like this
without duplicated code already we can copy from.

>> If $host_cpu heuristics are an improvement, then I don't think it hurts
>> to leave them, so that LT_SYS_LIBRARY_PATH is not always necessary.  Is
>> it the case that adding /lib64:/usr/lib64 is a pessimisation in some
>> case?
> 
> Cowardly, I know.., thats not what I initially said, sorry.  But more I
> read the history of this issue, more unsure I'm.  I'm not 100% against
> that so don't take me too seriously:
> 
> It has been proven it works for Fedora and it does not break Debian [1]
> (though that patch does not follow debian's policy).  On the other hand,
> taking into account there can be /usr/lib32-like GNU/Linux distributions..
> or just user setups..
> 
> If there are reasons to not apply this unconditionally at least for
> GNU/Linux (and there surely are), I'm not sure whether we shouldn't
> rather avoid such 'linux*' && subset(64-bit arches) only conditions
> (because reasons for not to do it must be the same).  And that can result
> in more tricky debugging scenarios.
> 
> [1] https://wiki.debian.org/RpathIssue
> 
> Pavel

Okay, I agree with your arguments, and will revert the hardcoded settings
before applying your patch.

Cheers,
Gary V. Vaughan (gary AT gnu DOT org)



reply via email to

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