GCC doesn't find relative includes when passed paths using backward-slashes

GCC doesn't find relative includes when passed paths using backward-slashes

[Alexander Grund]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

Hi,

consider the following MWE:

|$ touch bar/foo.h $ cat bar/main.cpp #include "foo.h" int main(){} With this most simple setup calling GCC with `g++ "bar\main.cpp"` results in GCC failing to find the include file. However using `g++ "bar/main.cpp"` works as expected. |
|So the compiler does find the CPP file and also is able to resolve others paths passed with backslashes (e.g. -I arguments) but basically disables resolving includes relative to the file including it. For context: This turned up on CI for Boost where "|C:\cygwin64\bin" is added to the PATH env variable to be able to use the Cygwin GCC with B2. The build system, finding it is running on Windows, will pass paths with backward slashes to the compiler. This happens on both CMD with the added PATH and using the bash. For reference I tried the same with MinGW and there either path separator worked. So it seems to be an issue in the Cygwin builds of GCC. I tried both 11.2 and 11.3, the latest currently available. Best Regards, Alexander Grund ||

Re: GCC doesn't find relative includes when passed paths using backward-slashes

[Hans-Bernhard Bröker]

Am 15.01.2023 um 13:38 schrieb Alexander Grund via Cygwin:

> The build system, finding it is running on Windows, will pass paths with 
> backward slashes to the compiler. 

And that's wrong.  Cygwin is not, for practical intents and purposes, 
Windows.  It just runs on top of it.

Yes, backslashed path names do work in some cases on Cygwin (note that 
in the case at hand, you did have to "" around the name for that to 
work).  But at some point that idea has to be given up to achieve the 
primary goal of emulating a Unix-like environment.

The correct solution thus becomes "Don't do that, then."  Fix the build 
system detection to recognize Cygwin as a type of Unix, and things will 
almost certainly just work.

Re: GCC doesn't find relative includes when passed paths using backward-slashes

[Thomas Wolff]

Am 15.01.2023 um 14:51 schrieb Hans-Bernhard Bröker via Cygwin:
> Am 15.01.2023 um 13:38 schrieb Alexander Grund via Cygwin:
>
>> The build system, finding it is running on Windows, will pass paths 
>> with backward slashes to the compiler. 
>
> And that's wrong.  Cygwin is not, for practical intents and purposes, 
> Windows.  It just runs on top of it.
>
> Yes, backslashed path names do work in some cases on Cygwin (note that 
> in the case at hand, you did have to "" around the name for that to 
> work).  But at some point that idea has to be given up to achieve the 
> primary goal of emulating a Unix-like environment.
>
> The correct solution thus becomes "Don't do that, then."  Fix the 
> build system detection to recognize Cygwin as a type of Unix, and 
> things will almost certainly just work.
>
>
It also depends on how your application, in this case gcc or rather cpp, 
handles path names.
If it uses library functions dirname and basename, it should work as you 
expect, but maybe it looks for '/' itself, so you cannot expect all 
applications to be patched for cygwin/Windows pathname support.

Re: GCC doesn't find relative includes when passed paths using backward-slashes

[Achim Gratz]

Alexander Grund via Cygwin writes:
> consider the following MWE:
>
> |$ touch bar/foo.h $ cat bar/main.cpp #include "foo.h" int main(){}
> |With this most simple setup calling GCC with `g++ "bar\main.cpp"`
> |results in GCC failing to find the include file. However using `g++
> |"bar/main.cpp"` works as expected. |

Giving any Cygwin tools non-POSIX path constructs is asking for trouble,
notwithstanding the fact that sometimes it works (or seems to work).

> |So the compiler does find the CPP file and also is able to resolve
> | others paths passed with backslashes (e.g. -I arguments) but
> | basically disables resolving includes relative to the file including
> | it. For context: This turned up on CI for Boost where
> | "|C:\cygwin64\bin" is added to the PATH env variable to be able to
> | use the Cygwin GCC with B2. The build system, finding it is running
> | on Windows, will pass paths with backward slashes to the
> | compiler.

Then use a build system that doesn't do this.

> | This happens on both CMD with the added PATH and using the
> | bash. For reference I tried the same with MinGW and there either
> | path separator worked. So it seems to be an issue in the Cygwin
> | builds of GCC.

No it isn't, just like you couldn't expect this to work on Linux.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: GCC doesn't find relative includes when passed paths using backward-slashes

[Dan Harkless]

On 1/15/2023 4:38 AM, Alexander Grund via Cygwin wrote:
> Hi,
>
> consider the following MWE:
>
> |$ touch bar/foo.h $ cat bar/main.cpp #include "foo.h" int main(){} With this most simple setup calling GCC with `g++ "bar\main.cpp"` results in GCC failing to find the include file. However using `g++ "bar/main.cpp"` works as expected. |
> |So the compiler does find the CPP file and also is able to resolve others paths passed with backslashes (e.g. -I arguments) but basically disables resolving includes relative to the file including it. For context: This turned up on CI for Boost where "|C:\cygwin64\bin" is added to the PATH env variable to be able to use the Cygwin GCC with B2. The build system, finding it is running on Windows, will pass paths with backward slashes to the compiler. This happens on both CMD with the added PATH and using the bash. For reference I tried the same with MinGW and there either path separator worked. So it seems to be an issue in the Cygwin builds of GCC. I tried both 11.2 and 11.3, the latest currently available. Best Regards, Alexander Grund ||

Backslash has a special meaning in C/C++ strings (the quote/escape 
character).  There's some kind of special magic in Cygwin bash that lets 
you use most backslashes in paths without escaping them, but ordinarily 
(outside of '-quotes) on UNIX/Cygwin you need to. If you use:

     g++ bar\\main.cpp

or:

     g++ "bar\\main.cpp"

or:

     g++ 'bar\main.cpp'

it'll work.

--
Dan Harkless
http://harkless.org/dan/