On Mon, Feb 11, 2002 at 20:47:56 +0100, Henning Meier-Geinitz wrote:
> On Mon, Feb 11, 2002 at 09:44:36AM +0000, Tim Waugh wrote:
> > sane-config --cflags shouldn't say '-I/usr/include', since that's the
> > default include path anyway; similarly, sane-config --libs shouldn't
> > say '-lc' (and it doesn't).
>
> Can we really assume that /usr/include is included on each and every
> platform? Is it in the C-standard or similar text?
>
> What is the problem with explicitely mentioning "/usr/include"? Does
> it break anything or makes it much slower?
Info: (gcc.info)Interoperation:
* Use of `-I/usr/include' may cause trouble.
Many systems come with header files that won't work with GCC unless
corrected by `fixincludes'. The corrected header files go in a new
directory; GCC searches this directory before `/usr/include'. If
you use `-I/usr/include', this tells GCC to search `/usr/include'
earlier on, before the corrected headers. The result is that you
get the uncorrected header files.
Instead, you should use these options (when compiling C programs):
-I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include
For C++ programs, GCC also uses a special directory that defines
C++ interfaces to standard C subroutines. This directory is meant
to be searched *before* other standard include directories, so
that it takes precedence. If you are compiling C++ programs and
specifying include directories explicitly, use this option first,
then the two options above:
-I/usr/local/lib/g++-include
May be `fixincludes' is only a concern on older systems. But there is a
problem with C++ <complex.h> - it is different from the C one in
/usr/include, so adding -I/usr/include might break a C++ frontend which
uses complex numbers.
Also, -I/usr/include may interfere with user-specified include paths -
sometimes you may want to compile a program with a library version
different from the one installed in /usr, and with -I/usr/include the
system-installed headers may be picked up anyway. Same problem with
-L/usr/lib.
