problem with GCC search path on FreeBSD5.3 AMD64
tedm at toybox.placo.com
Tue Feb 15 12:15:11 GMT 2005
> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Maicon Stihler
> Sent: Monday, February 14, 2005 10:18 AM
> To: freebsd-questions at freebsd.org
> Subject: problem with GCC search path on FreeBSD5.3 AMD64
> I installed FreeBSD 5.3 for AMD64 on my computer following the
> standard procedure. To my surprise, when I tried to compile new
> packages I find out that /usr/local/lib and /usr/local/include wasnt
> on gcc's search path. As a workaround I compiled the packages with
> CFLAGS="-B /usr/local/lib -I/usr/local/include".
> As far as I know, and the gcc info pages seems to agree, these too
> directories should be in the default search path.
this isn't a gcc problem.
> Is someone else experiencing this same problem?
> Is there a way to add these directories to the default path without
> resorting to these env variables or runtime switches?
However, most packages use the -R and -L flags to the linker if they
are linking to a shared library in /usr/local/lib because not all
UNIX systems provide a ldconfig-type utility, and it is more portable
to hard code it. Note that if your generating a library, don't use
either of these flags. Libraries that depend on other dynamic libraries
(such as openssl's libraries that can be linked to zlib) at runtime
should confine themselves to only linking to libraries in /usr/lib (or
There are pros and cons to using the hints file that ldconfig generates
vs compiling in the runtime location of the libraries. Neither is
better than the other.
Another trick used is to softlink the library from /usr/local/lib to
The LD_LIBRARY_PATH variable should never be used except for testing
More information about the freebsd-questions