public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: preprocessor/5940: CPP problem when header has same name as dir in previously in search path
@ 2002-03-13 15:03 neil
0 siblings, 0 replies; 2+ messages in thread
From: neil @ 2002-03-13 15:03 UTC (permalink / raw)
To: cholm, gcc-bugs, gcc-prs, neil, nobody
Synopsis: CPP problem when header has same name as dir in previously in search path
Responsible-Changed-From-To: unassigned->neil
Responsible-Changed-By: neil
Responsible-Changed-When: Wed Mar 13 15:03:29 2002
Responsible-Changed-Why:
.
State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Wed Mar 13 15:03:29 2002
State-Changed-Why:
Thanks for your bug report.
I don't have 3.0.3 lying around, but 3.0.4 and 3.1 continue searching for the header even if a directory of the same name matches.
The error message you posted I have reproduced with 2.95.4, but not 3.0.4 or 3.1. This particular bug was fixed recently, but I'm not sure when. Maybe 3.0.3 -> 3.0.4 was the time.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5940
^ permalink raw reply [flat|nested] 2+ messages in thread
* preprocessor/5940: CPP problem when header has same name as dir in previously in search path
@ 2002-03-13 10:56 cholm
0 siblings, 0 replies; 2+ messages in thread
From: cholm @ 2002-03-13 10:56 UTC (permalink / raw)
To: gcc-gnats, debian-gcc
>Number: 5940
>Category: preprocessor
>Synopsis: CPP problem when header has same name as dir in previously in search path
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Mar 13 10:56:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Christian Holm Christensen
>Release: 3.0.3 (Debian testing/unstable)
>Organization:
>Environment:
System: Linux scharff.fys.ku.dk 2.2.17 #2 SMP Tue Nov 14 17:20:25 CET 2000 i686 unknown
Architecture: i686
host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: i386-pc-linux-gnu
configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux
>Description:
If an `#include' directive, wether it a "..." or a <...> which matches a
directory name in the search path, will make CPP try to include that
directory, regardless of wether there's an actual file later on in the
search.
This problem is present in EGCS 2.91.66, GCC 2.93.4, `GCC 2.96-RH', and
GCC 3.0.3.
It may be that I'm doing things wrong, but I do believe the interface is
rather contra-intutive in that case.
I did not find anything in the documentation that could help me on this.
>How-To-Repeat:
Make the directory `stdio.h':
prompt% mkdir -p stdio.h
Make a file (say foo.c) in the current directory, with the contenst:
#include <stdio.h>
int main() {
printf("Hello World\n");
return 0;
}
Try to compile this as
prompt% gcc -c -I. foo.c
It will fail with:
foo.c:1: directory `stdio.h' specified in #include
I know that `stdio.h' is not a common name for a directory, but imagine
something like `new' in C++ code.
>Fix:
If one uses `-idirafter .' rather then `-I.', then everything works fine.
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-03-13 23:03 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-13 15:03 preprocessor/5940: CPP problem when header has same name as dir in previously in search path neil
-- strict thread matches above, loose matches on Subject: below --
2002-03-13 10:56 cholm
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).