keeping source trees

Nelson Arzola narzola at
Wed Jun 7 00:59:45 PDT 2000

Gerard Beekmans writes:

> > > compile a C program with: gcc --verbose -c filename.c
> > >
> > > the verbose output includes the paths gcc looks in for include files
> >
> > That did the trick, it isn't looking in /usr/local/include allright, now
> > to figure out how to modify this...i have no idea where to begin.
> >
> > Should this be mentioned in the book? (and the fix)
> I tried it myself and also found it doesn't scan /usr/local/include
> This should definitely be fixed, but I have no idea how to do that as of
> yet. I guess when somebody reads the FAQ or INSTALL files it should
> become clear, but that someone isn't going to be me for a little while.
> If somebody figures it out before I do, let us know. I've put it on the
> TODO list so I will address some point.

After carefully looking at a current LFS system, I think you did not create
the link from "/usr/local" --> "/usr".  If this is true, then when you
compiled GCC, you should not have used the config statement
"--with-local-prefix=/usr".  According to the online GCC documentation, this
will override where GCC thinks /usr/local is.  (People who prefer an /opt
directory tree might want GCC's idea of /usr/local to be /opt/include).

If you want the correct fix, recompile GCC without the
"--with-local-prefix=/usr" option.  The next paragraph contains the
pertinent documentation about this option.  Recompiling GCC takes a long
time.  If you want a quick fix, skip this next paragraph and keep reading:

     4. The standard directory for installing GNU CC is `/usr/local/lib'.
         If you want to install its files somewhere else, specify
          `--prefix=DIR' when you run `configure'.  Here DIR is a directory
          name to use instead of `/usr/local' for all purposes with one
          exception: the directory `/usr/local/include' is searched for
          header files no matter where you install the compiler.  To
          this name, use the `--with-local-prefix' option below.  The
          directory you specify need not exist, but its parent directory
          must exist.

The quick and easy fix is to find CFLAGS in the Makefile and add
"-I/usr/local/include" to it.  Then find LDFLAGS and add "-L/usr/local/lib"
to it.  This is not the ideal fix because it only solves your problem once.
The pertinent online documentation is listed below:

     Add the directory DIR to the head of the list of directories to be
     searched for header files.  This can be used to override a system
     header file, substituting your own version, since these
     directories are searched before the system header file
     directories.  If you use more than one `-I' option, the
     directories are scanned in left-to-right order; the standard
     system directories come after.

     Any directories you specify with `-I' options before the `-I-'
     option are searched only for the case of `#include "FILE"'; they
     are not searched for `#include <FILE>'.

     If additional directories are specified with `-I' options after
     the `-I-', these directories are searched for all `#include'
     directives.  (Ordinarily _all_ `-I' directories are used this way.)

     In addition, the `-I-' option inhibits the use of the current
     directory (where the current input file came from) as the first
     search directory for `#include "FILE"'.  There is no way to
     override this effect of `-I-'.  With `-I.' you can specify
     searching the directory which was current when the compiler was
     invoked.  That is not exactly the same as what the preprocessor
     does by default, but it is often satisfactory.

     `-I-' does not inhibit the use of the standard system directories
     for header files.  Thus, `-I-' and `-nostdinc' are independent.

Hope this helps,

Nelson Arzola

Mail archive:
IRC access: server: port: 6667 channel: #LFS
News Reader access:
Unsubscribe: email lfs-discuss-request at and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)

More information about the lfs-dev mailing list