Norman Vine wrote:
> Greg Chicares
> >In the following example, creating a directory named 'new' on the
> >include path makes the system header <new> inaccessible. Is this
> >expected behavior?
> Ahh.. Deja Vu.
> See thread starting at
Thanks. I thought I might have misunderstood some arcane rule for
gcc directory searches.
In this message
> Can you tell us exactly what happened so that we'll know next
> time somebody runs into something similar (and you know that's
> bound to happen!)?
> Is it because you had directory named `new' in the include
> search list? If so, then the bug is deep inside of win32 API
> which refuses to "open" directories like on Unix and I'd
> like to provide a way around it.
That was my problem (test case in original posting). It's not
confined to <new>; it looks like it happens whenever there's
a directory with the same name as a header. It doesn't matter
whether it's included with <>
For example, after setting up three such directories, I get:
C:\testing>g++ -I. -c oops.cpp
oops.cpp:1: cmath: Permission denied
oops.cpp:2: vector: Permission denied
oops.cpp:3: float.h: Permission denied
So, at least with the default 2.95.2-1 setup, it's a very bad
idea to name a header <objc>, since that's a subdirectory of
a system header directory.