conflict include file names found in gcc-3.4.1

conflict include file names found in gcc-3.4.1

[Paul Lew]

Platform:

    > uname -r
    2.4.20-20.7.cisco.4smp

    > gcc -v
    Reading specs from
    /auto/insbu-cnstools/libx86/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
    gcc version 2.95.3 20010315 (release)

Problem:

    Got error reporting that OPT_A, ... not defined when compiling
    c-opts.c.

Reason: 

    Another include file 'options.h' (provided by autogen) installed
    in a location before local options.h is found.

Recommendation:

    (1) fix the include path so that local directory will be scanned
	first, it has:

	gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings
	    -Wstrict-prototypes -Wmissing-prototypes -pedantic
	    -Wno-long-long -DHAVE_CONFIG_H
	    -I/auto/insbu-cnstools/include -I. -I.
	    -I../../gcc-3.4.1/gcc -I../../gcc-3.4.1/gcc/.
	    -I../../gcc-3.4.1/gcc/../include 
	    ../../gcc-3.4.1/gcc/c-opts.c -o c-opts.o
	
	The /auto/insbu-cnstools/include inserted here might contains
	other include files with the same name.  It will be safer to
	put this at the end.

    (2) change the file name.  Although autogen is also at fault, to
        avoid this kind of name clash, rename options.h to something
        like gcc_options.h will likely prevent this from happening.

Re: conflict include file names found in gcc-3.4.1

[James E Wilson]

Paul Lew wrote:
>     > uname -r
>     2.4.20-20.7.cisco.4smp

This doesn't give me any useful info about the target.  This is just a 
kernel version.  I need CPU architecture, OS, etc.

See
     http://gcc.gnu.org/bugs.html
for info on reporting bugs.

> 	    -I/auto/insbu-cnstools/include -I. -I.
> 	    -I../../gcc-3.4.1/gcc -I../../gcc-3.4.1/gcc/.
> 	    -I../../gcc-3.4.1/gcc/../include 
> 	    ../../gcc-3.4.1/gcc/c-opts.c -o c-opts.o

If you look at the FSF gcc Makefile, you will see that -I. is the first 
directory in the include path.  Look at the INCLUDES rule.

I am guessing that you have local modifications that add the 
-I/auto/insbu-cnstools/include directory, and that these local mods are 
putting it in the wrong place.

If this is an FSF gcc problem, you will have to explain where the 
-I/auto/... is coming from.  I don't see any explanation other than 
local mods.

The problem here may be that you did not give us complete info.  We need 
to know how to reproduce the problem before we can fix it, and that 
includes info such as how you configured gcc.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: conflict include file names found in gcc-3.4.1

[Paul Lew]

>>>>> "James" == James E Wilson <wilson@specifixinc.com> writes:

    >> > uname -r
    >> 2.4.20-20.7.cisco.4smp

    James> This doesn't give me any useful info about the target.
    James> This is just a kernel version.  I need CPU architecture,
    James> OS, etc.

solaris 2.6 (sunos5.6), sparc.

    >> -I/auto/insbu-cnstools/include -I. -I.
    >> -I../../gcc-3.4.1/gcc -I../../gcc-3.4.1/gcc/.
    >> -I../../gcc-3.4.1/gcc/../include 
    >> ../../gcc-3.4.1/gcc/c-opts.c -o c-opts.o

    James> If you look at the FSF gcc Makefile, you will see that
    James> -I. is the first directory in the include path.  Look at
    James> the INCLUDES rule.

Not always.

    James> I am guessing that you have local modifications that add
    James> the -I/auto/insbu-cnstools/include directory, and that
    James> these local mods are putting it in the wrong place.

There is no local modification, there are extra parameters added
to configure that cause this to happen.

    James> If this is an FSF gcc problem, you will have to explain
    James> where the -I/auto/... is coming from.  I don't see any
    James> explanation other than local mods.

    James> The problem here may be that you did not give us complete
    James> info.  We need to know how to reproduce the problem before
    James> we can fix it, and that includes info such as how you
    James> configured gcc.

The command to build c-opts.o is:

gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
    -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H
    -I/auto/insbu-cnstools/include
    -I. -I.
    -I../../gcc-3.4.1/gcc
    -I../../gcc-3.4.1/gcc/. -I../../gcc-3.4.1/gcc/../include
    ../../gcc-3.4.1/gcc/c-opts.c -o c-opts.o

As you can see, the first -I is not '.', the autogen puts options.h
in /auto/insbu-cnstools/inlcude and therefore c-opts.c will get
the wrong options.h.

The configure command looks like:

> ../gcc-3.4.1/configure --prefix=/auto/insbu-cnstools
	 --bindir=/auto/insbu-cnstools/binx86
	 --libdir=/auto/insbu-cnstools/libx86
	 --disable-nls
	 --with-libiconv-prefix=/auto/insbu-cnstools

I believe the handling of --with-libiconv-prefix parameter is not
correct.

Re: conflict include file names found in gcc-3.4.1

[James E Wilson]

On Tue, 2004-08-24 at 18:47, Paul Lew wrote:
>     James> If you look at the FSF gcc Makefile, you will see that
>     James> -I. is the first directory in the include path.  Look at
>     James> the INCLUDES rule.
> Not always.

You didn't read what I wrote.  I clearly said Makefile and INCLUDES.  If
you actually bothered to look at the Makefile, you would see that I am
right.

> There is no local modification, there are extra parameters added
> to configure that cause this to happen.

This is the vital clue that you left out of your earlier bug report.

> I believe the handling of --with-libiconv-prefix parameter is not
> correct.

Yes.  Note that this configure option does not modify INCLUDES.  It
modifies CPPFLAGS which is wrong.

Now that you have enough info for a proper bug report, please file one
into our bugzilla database.  We do not track bug reported to the
gcc-bugs mailing list.  We only track bugs filed into our bug database. 
See
   http://gcc.gnu.org/bugs.html
for more info on reporting bugs.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: conflict include file names found in gcc-3.4.1

[Paul Lew]

>>>>> "James" == James E Wilson <wilson@specifixinc.com> writes:

    James> If you look at the FSF gcc Makefile, you will see that
    James> -I. is the first directory in the include path.  Look at
    James> the INCLUDES rule.

    >> Not always.

    James> You didn't read what I wrote.  I clearly said Makefile and
    James> INCLUDES.  If you actually bothered to look at the
    James> Makefile, you would see that I am right.

    >> There is no local modification, there are extra parameters
    >> added to configure that cause this to happen.

    James> This is the vital clue that you left out of your earlier
    James> bug report.

    >> I believe the handling of --with-libiconv-prefix parameter is
    >> not correct.

    James> Yes.  Note that this configure option does not modify
    James> INCLUDES.  It modifies CPPFLAGS which is wrong.

    James> Now that you have enough info for a proper bug report,
    James> please file one into our bugzilla database.  We do not
    James> track bug reported to the gcc-bugs mailing list.  We only
    James> track bugs filed into our bug database.  See
    James> http://gcc.gnu.org/bugs.html for more info on reporting
    James> bugs.

Will do, thanks for confirming the problem.