Re: AC_CHECK_HEADERS works but AC_SEARCH_LIBS does not

[Olaf Weber]

Thomas Dickey writes:
> On Mon, 13 Dec 2004, Paul Eggert wrote:
>> Sam Steingold <address@hidden> 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.)