[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_dlsea
From: |
Pavel Raiskup |
Subject: |
Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_dlsearch_path_spec) |
Date: |
Tue, 09 Dec 2014 09:14:30 +0100 |
User-agent: |
KMail/4.14.3 (Linux/3.17.4-200.fc20.x86_64; KDE/4.14.3; x86_64; ; ) |
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"}?
> 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
- Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec, Gary V. Vaughan, 2014/12/04
- Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec, Pavel Raiskup, 2014/12/05
- Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec, Gary V. Vaughan, 2014/12/05
- Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec, Pavel Raiskup, 2014/12/05
- Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec, Gary V. Vaughan, 2014/12/05
- Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec, Pavel Raiskup, 2014/12/06
- Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec, Pavel Raiskup, 2014/12/08
- Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec, Gary V. Vaughan, 2014/12/08
- Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_dlsearch_path_spec),
Pavel Raiskup <=
- Re: Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_dlsearch_path_spec), Gary V. Vaughan, 2014/12/09
- Re: Tune rpath by env. variable, Pavel Raiskup, 2014/12/09
- Re: Tune rpath by env. variable, Gary V. Vaughan, 2014/12/09
- Re: Tune rpath by env. variable, Pavel Raiskup, 2014/12/10
- Re: Tune rpath by env. variable, Gary V. Vaughan, 2014/12/11
- Re: Tune rpath by env. variable, Pavel Raiskup, 2014/12/12
- Re: Tune rpath by env. variable, Gary V. Vaughan, 2014/12/12
- Re: Tune rpath by env. variable, Pavel Raiskup, 2014/12/13
Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec, Orion Poplawski, 2014/12/05