Re: gcc-3.4.4 and the '-I' switch.

Re: gcc-3.4.4 and the '-I' switch.

[Danny Smith]

Forwarding to mingw list from gcc-help:
"Sisyphus" <isyphus1 at optusnet dot com dot au> wrote: 
 
> Hi,
> On linux I'm using gcc 3.2.2. If I run a command like:
> 
> gcc -c foo.c -I/usr/include -v
> 
> then I'm told that '-I/usr/include/' is being ignored "as it is a
non-system
> directory that duplicates a system directory".
> 
> That's good - and the way it should be, imho.
> 
> On Win32 I'm using the MinGW port of gcc 3.4.4. One of the system
> directories is 'D:/MinGW/include'. If, on Win32, I run a command like:
> 
> gcc -c foo.c -ID:/MinGW/include -v
> 
> then I find that D:/MinGW/include is simply inserted at the beginning
of the
> search path - and, furthermore, that D:/MinGW/include *loses* its
status as
> a system directory.
> 
> This is not good.
> 

I think the problem is that, because of lack of meaningful inode
numbers, the mechanism to detect duplicate directories in
gcc/c-incpath.c: remove_duplicates fails. Hence, we cannot ignore
duplicates of system directories on mingw32. Replacing INO_T_EQ with a
mingw-host function that does a strcmp of lrealpath() pathnames works.

Danny

> The question:
> Do I raise this with you people, or do I raise it with the MinGW folk
?
> 
> I *think* it's a MinGW implemenation issue (in which case I raise it
with
> them) .... but, faik, it could be something that changed between
gcc-3.2.2
> and gcc-3.4.4. Can someone confirm ?
> 
> Cheers,
> Rob

Re: [Mingw-users] Re: gcc-3.4.4 and the '-I' switch.

[Sisyphus]

----- Original Message ----- 
From: "Danny Smith" <dannysmith@clear.net.nz>
To: <syphus1@optusnet.com.au>
Cc: <GCC-help@gcc.gnu.org>; <mingw-users@lists.sourceforge.net>

>
> I think the problem is that, because of lack of meaningful inode
> numbers, the mechanism to detect duplicate directories in
> gcc/c-incpath.c: remove_duplicates fails. Hence, we cannot ignore
> duplicates of system directories on mingw32. Replacing INO_T_EQ with a
> mingw-host function that does a strcmp of lrealpath() pathnames works.
>

I assume that a "strcmp of lrealpath() pathnames" will detect that, for
example, "D:/MinGW/include" and
"D:/MinGW/bin/../lib/gcc/mingw32/3.4.4/../../../../include" are one and the
same ? (Sorry - I'm ignorant of what the lrealpath function does.)

Anyway ... assuming that my assumption is correct  :-) .... that sounds fine
to me.

Cheers,
Rob

gcc-3.4.4 and the '-I' switch.

[Sisyphus]

Hi,
On linux I'm using gcc 3.2.2. If I run a command like:

gcc -c foo.c -I/usr/include -v

then I'm told that '-I/usr/include/' is being ignored "as it is a non-system
directory that duplicates a system directory".

That's good - and the way it should be, imho.

On Win32 I'm using the MinGW port of gcc 3.4.4. One of the system
directories is 'D:/MinGW/include'. If, on Win32, I run a command like:

gcc -c foo.c -ID:/MinGW/include -v

then I find that D:/MinGW/include is simply inserted at the beginning of the
search path - and, furthermore, that D:/MinGW/include *loses* its status as
a system directory.

This is not good.

The question:
Do I raise this with you people, or do I raise it with the MinGW folk ?

I *think* it's a MinGW implemenation issue (in which case I raise it with
them) .... but, faik, it could be something that changed between gcc-3.2.2
and gcc-3.4.4. Can someone confirm ?

Cheers,
Rob