Thomas Dickey writes: > On Mon, 13 Dec 2004, Paul Eggert wrote: >> Sam Steingold <sds@xxxxxxx> writes: >>> how come gcc looks in /usr/local/include but not in /usr/local/lib? >> That's more of a GCC question than an Autoconf question. It's a long >> story; for a first cut you can look here: > only a small cut, since it doesn't explain why it was a bad idea (nor any > of the related changes over the past ten years). Perhaps you can offer > a better url. >> http://gcc.gnu.org/faq.html#rpath Actually, the problem with the link is that it answers a different, if related, question. And there I agree that turning each -L into an implicit -R (or -rpath) is a bad idea: the resulting DT_RPATH in the (ELF) binary may not be correct (for example because the -L referred to the library not yet installed). And on many systems the DT_RPATH is searched before $LD_LIBRARY_PATH, which means that if the wrong library is found through the DT_RPATH, the obvious corrective measure will not work. As for the original question: a compiler should only search /usr/local/lib for (shared) libraries if the runtime loader does so as well. Otherwise you can silently get differences between the libraries found when compiling and when actually running the binary. Given a platform where '-L/usr/local/lib' is needed, should gcc be searching /usr/local/include if no '-I/usr/local/include' was given? To be honest, my opinion is that it should not. -- Olaf Weber (This space left blank for technical reasons.) _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
