X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3EE453858017 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1673799817; bh=m3enBVLxBptIjkFN44mTeyWZnb176enhfpYrZ3x4kCc=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=xCwkZqeQjhS9AOGUSptZTHqQlXexDXdKmBWs657ZwFvKV4M3seMuIJ7TETJgE0ci9 qiQHsX40DYCUBDLKynIPGy0asR946V+5TR1CB+2/MMy80QZf5G41aGAV+if3i5KTpR i7+WIBpk1jc4To9rhBujm8W5oiVrkaGJ7xGMtXH8= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DC0F83858D37 To: cygwin AT cygwin DOT com Subject: Re: GCC doesn't find relative includes when passed paths using backward-slashes References: Date: Sun, 15 Jan 2023 17:23:08 +0100 In-Reply-To: (Alexander Grund via Cygwin's message of "Sun, 15 Jan 2023 13:38:31 +0100") Message-ID: <87edrv6a37.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-purgate-type: clean X-purgate: clean X-purgate-size: 1507 X-purgate-ID: 155817::1673799795-FBFE64DE-53342669/0/0 X-Spam-Status: No, score=-3031.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Achim Gratz via Cygwin Reply-To: Achim Gratz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple