Date: Tue, 28 May 2002 12:31:07 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Antoine Beaupre <anarcat@anarcat.ath.cx> Cc: Greg 'groggy' Lehey <grog@FreeBSD.org>, FreeBSD-arch@FreeBSD.org Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <3CF3DAFB.7C9C5108@mindspring.com> References: <26911A2E-7243-11D6-93A2-0050E4A0BB3F@anarcat.ath.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Antoine Beaupre wrote:
> We could still make the ports system try to use libraries in
> /usr/local/lib too by default since most third party apps have
> dependencies on other third-party apps.
>
> The way I usually do it is:
>
> CONFIGURE_ENV+= CPPFLAGS="-I${LOCALBASE}/include" \
> LDFLAGS="-L${LOCALBASE}/lib" \
> CFLAGS="-I${LOCALBASE}/include ${CFLAGS}" \
> CXXFLAGS="-I${LOCALBASE}/include ${CXXFLAGS}"
>
> or something like that. I think a lot of ports have something like that
> in there somewhere.
The resulting binaries still do not work, unless LD_LIBRARY_PATH
is set, or there is an intervening run of "ldconfig". They fail
to find shared libraries at runtime, installed after boot but
before link (the libraries are found at link time, just not at
runtime).
It seems to me that either the ld should fail to find the libraries
at link time if it's not going to find them at runtime, or it should
find them at runtime if it found them at link time. But ldconfig is
more than it should be... it's more of a csh "rehash" of the path
hash, when it should probably be a tcsh "rehash": search the hash
first, and on failure, search the PATH (adding to the hash automatically
on a success would be the wrong thing to do, but finding it would not
be).
It's really annoying to have one algorithm for linking and another
for running. I don't really understand the value of this assymetry;
I guess it's intended to allow you to build without properly
installing libraries on the build system. In practice, however, it
is never really done this way in "ports" or other places, or the
packages builds would not have to take place on virtually "clean"
systems in order to ensure that a dependency is not missed.
I put this one down to the lack of care taken in preparation of ports,
to ensure that paths are limited on install and build, so that it should
be possible to use a different PREFIX per port, and build simultaneously,
without it "finding" things it shouldn't. If *that* were possible,
then automatically finding headers and libraries in /usr/local during
the build would *definitely* be the wrong thing to do: the local system
would effect the dependency satisfaction of a package build when it
shouldn't.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CF3DAFB.7C9C5108>