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 _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool