Home/ Questions/Q 9157619
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T13:04:19+00:00

I’m trying to compile gcc-4.7.2 from source using gcc-4.6.1. First I run the contrib/download_prerequisites

  • 0

I’m trying to compile gcc-4.7.2 from source using gcc-4.6.1.

First I run the contrib/download_prerequisites to download the required packages then follow instructions on LFS http://www.linuxfromscratch.org/blfs/view/svn/general/gcc.html

when running make bootstrap, I got the error message:

In file included from ../../gcc-4.7.2/gcc/c-lang.c:24:0:
../../gcc-4.7.2/gcc/system.h:499:20: error: conflicting types for ‘strsignal’
/usr/include/string.h:566:14: note: previous declaration of ‘strsignal’ was here

My situation is the same as the one posted here: http://gcc.gnu.org/ml/gcc-help/2011-12/msg00062.html . The reason is also the same: gcc finds the wrong config.h, which should be the one at the current directory, but actually it uses the one under gmp.

I find the reason is that, even though the command line specify -I. before all other -I options, -I. is ignored because it is already in the standard search path. Here is the message I got via running gcc -v:

ignoring duplicate directory "."
as it is a non-system directory that duplicates a system directory

Here is the order of path searching related to this problem ( http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html ):
“The only exception is when dir is already searched by default. In this case, the option is ignored and the search order for system directories remains unchanged.”

What can I do to make gcc search the current directory before other paths specified by -I options?

The command that yield the error message is:

gcc -c  -DIN_GCC_FRONTEND -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7.2/gcc -I../../gcc-4.7.2/gcc/. -I../../gcc-4.7.2/gcc/../include -I../../gcc-4.7.2/gcc/../libcpp/include -I/home/dwang/Downloads/gcc-build/./gmp -I/home/dwang/Downloads/gcc-4.7.2/gmp -I/home/dwang/Downloads/gcc-build/./mpfr -I/home/dwang/Downloads/gcc-4.7.2/mpfr -I/home/dwang/Downloads/gcc-4.7.2/mpc/src  -I../../gcc-4.7.2/gcc/../libdecnumber -I../../gcc-4.7.2/gcc/../libdecnumber/bid -I../libdecnumber    ../../gcc-4.7.2/gcc/c-lang.c -o c-lang.o

Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This turns out to be a very wired configuration problem in my ~/.bashrc. I used to add the following line to bashrc:

    export C_INCLUDE_PATH=/home/dwang/local/include:/export/scratch/packages/include/:$C_INCLUDE_PATH

    The output of echo $C_INCLUDE_PATH is:

    /home/dwang/local/include:/export/scratch/packages/include/:

    It turns out that if there is a trailing : in the C_INCLUDE_PATH, then . is also added. If I remove the trailing :, everything is fine.

    The reason is documented here:

    In all these variables, an empty element instructs the compiler to search its current working directory. Empty elements can appear at the beginning or end of a path. For instance, if the value of CPATH is :/special/include, that has the same effect as `-I. -I/special/include’.

    • 0