[remembered to remove Orion from the Cc: list this time as requested] Hi Pavel,
> On 9 Dec 2014, at 08:14, Pavel Raiskup <prais...@redhat.com> 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) _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool