Re: [Mingw-users] -I option failing with trailing slashes

Quoting Keith MARSHALL <keith.marshall@...>:
> Gianluca Sforna wrote:
>> It seems that passing to g++ a -I option with a trailing slash like:
>> -I"inc/"
>> results in the compiler failing to find include files; I did not test
>> with gcc but I guess it is the same.
>
> Is this in MSYS? IIRC, it is a bug in the MSYS path handling logic.
> It has been reported before; I don't know when it might get fixed. For
> now, the solution is to avoid trailing slashes after `-I path'.
>
No, it is GCC and fixed already IIRC. The issue is that winders
doesn't like c:\path\to\\myfile and chokes. So the fix in GCC would
have been to remove the trailing / or \ before suffixing it with the
/filename.
Earnie Boyd
http://shop.siebunlimited.com

Thread view

It seems that passing to g++ a -I option with a trailing slash like:
-I"inc/"
results in the compiler failing to find include files; I did not test
with gcc but I guess it is the same.
a simple test case:
test.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
#include "test.h"
int main ( int argc, char * argv[] )
{
A a;
return 0;
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
inc/test.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
class A {
public:
A() {};
private:
int x;
};
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
in linux both:
g++ -I"inc/" test.cpp -o test
and:
g++ -I"inc" test.cpp -o test
works as expected.
with MinGW (5.0.2), the latter works, while the former produce an error:
test.cpp:1:18 test.h: No such file or directory
Is this a bug or am I missing something?

Gianluca Sforna wrote:
> It seems that passing to g++ a -I option with a trailing slash like:
> -I"inc/"
> results in the compiler failing to find include files; I did not test
> with gcc but I guess it is the same.
Is this in MSYS? IIRC, it is a bug in the MSYS path handling logic.
It has been reported before; I don't know when it might get fixed. For
now, the solution is to avoid trailing slashes after `-I path'.
Regards,
Keith.

Quoting Keith MARSHALL <keith.marshall@...>:
> Gianluca Sforna wrote:
>> It seems that passing to g++ a -I option with a trailing slash like:
>> -I"inc/"
>> results in the compiler failing to find include files; I did not test
>> with gcc but I guess it is the same.
>
> Is this in MSYS? IIRC, it is a bug in the MSYS path handling logic.
> It has been reported before; I don't know when it might get fixed. For
> now, the solution is to avoid trailing slashes after `-I path'.
>
No, it is GCC and fixed already IIRC. The issue is that winders
doesn't like c:\path\to\\myfile and chokes. So the fix in GCC would
have been to remove the trailing / or \ before suffixing it with the
/filename.
Earnie Boyd
http://shop.siebunlimited.com

On 5/17/06, Earnie Boyd <earnie@...> wrote:
>
> No, it is GCC and fixed already IIRC. The issue is that winders
> doesn't like c:\path\to\\myfile and chokes. So the fix in GCC would
> have been to remove the trailing / or \ before suffixing it with the
> /filename.
Which version has this fixed?
I finally managed to compile Qt apps from msys (I had / translation
problems before) and this seems to be last missing piece, albeit not a
real blocker.
It is only preventing me from putting moc and uic produced files in
their own subdirectories, because qmake insist on adding a / to the
path I set for them.
Thanks in advance

On 5/17/06, Keith MARSHALL <keith.marshall@...> wrote:
> Gianluca Sforna wrote:
> > It seems that passing to g++ a -I option with a trailing slash like:
> > -I"inc/"
> > results in the compiler failing to find include files; I did not test
> > with gcc but I guess it is the same.
>
> Is this in MSYS? IIRC, it is a bug in the MSYS path handling logic.
> It has been reported before; I don't know when it might get fixed. For
> now, the solution is to avoid trailing slashes after `-I path'.
>
Yes, msys, but I tried also in cmd.exe with the very same results