DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AE034385B524
Message-ID: <dbce604a-f7ac-e30f-19db-609a71d2757e@Shaw.ca>
Date: Wed, 5 Jul 2023 17:08:34 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: iostream doesn't work (clang++)
Content-Language: en-CA
To: cygwin AT cygwin DOT com
References: <7e07e251-2ec6-b7a5-62da-8578eb638993 AT gmail DOT com>
 <47f9e50d-763b-e6a9-b2b0-8d3cc311a63b AT maxrnd DOT com>
 <3c02f650-248e-9e03-94a8-d508c857474e AT gmail DOT com>
Organization: Inglis
In-Reply-To: <3c02f650-248e-9e03-94a8-d508c857474e@gmail.com>
Precedence: list
From: Brian Inglis via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Brian Inglis <Brian DOT Inglis AT Shaw DOT ca>, ggl329 <ggl329 AT gmail DOT com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

On 2023-07-05 09:54, ggl329 via Cygwin wrote:
> Hi Mark,
> 
> On 2023/07/05 12:06, Mark Geisert via Cygwin wrote:
>> My previous reply addressed the specific error reported by your testcase.
>> But I am unable to make progress on the root cause because I can't reproduce 
>> your report.
> 
> Hm, it seems to be difficult to track down the root cause...
> 
>> On my system I try the compilation and see:
>> ~ clang++ sample.cc
>> sample.cc:1:10: fatal error: 'iostream' file not found
>> #include <iostream>
>>           ^~~~~~~~~~
>> 1 error generated.
> 
> I tried with clang++ --verbose, and the log showed search paths for #include.
> iostream is at /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iostream.
> Can you find it? It comes from gcc-g++.
> Or the search path includes /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++?

Package clang pulls in headers and libraries from libc++-devel libclang8 
libunwind-devel gcc-g++ libstdc++6 gcc-core cygwin-devel so the primary include 
paths should be from:
libc++-devel /usr/include/c++/v1/ for most language and library definitions and 
libraries,
libclang8 /usr/lib/clang/8.0.1/include/ for clang intrinsics and builtins,
libunwind-devel /usr/include/ for exception handling definitions and libraries,
gcc-g++ /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/{x86_64-pc-cygwin/,} and 
libstdc++6 for C++ system dependent and low level definitions and libraries,
gcc-core /usr/lib/gcc/x86_64-pc-cygwin/11/include/ for system dependent and low 
level intrinsics and interfaces, and
cygwin-devel /usr/include/{*/,} for system dependent and low level definitions 
and libraries.

Everything clang should be prioritized over anything gcc to prevent such issues, 
so cygcheck -c clang llvm libc++-devel libclang8 libunwind-devel gcc-g++ 
libstdc++6 gcc-core cygwin-devel to ensure eveything has been installed properly.

Unfortunately clang{,++,-cpp} -print-search-dirs does *NOT* show include paths,
but -v and -### complain about nonexistent /usr/include/c++/11 where 
/usr/include/c++/v1 exists!
It appears the search list ignores the directories populated in libc++-devel:
... -resource-dir /usr/lib/clang/8.0.1
-internal-isystem /usr/x86_64-pc-cygwin/include/c++
-internal-isystem /usr/x86_64-pc-cygwin/include/c++/x86_64-pc-cygwin
-internal-isystem /usr/x86_64-pc-cygwin/include/c++/backward
-internal-isystem /usr/x86_64-pc-cygwin/include/c++/11
-internal-isystem /usr/x86_64-pc-cygwin/include/c++/11/x86_64-pc-cygwin 
-internal-isystem /usr/x86_64-pc-cygwin/include/c++/11/backward
-internal-isystem /usr/include/c++/11
-internal-isystem /usr/include/c++/11/x86_64-pc-cygwin
-internal-isystem /usr/include/c++/11/backward
-internal-isystem /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++
-internal-isystem /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin 
-internal-isystem /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/backward
-internal-isystem /usr/lib/clang/8.0.1/include
-internal-isystem /usr/local/include
-internal-isystem /usr/lib/clang/8.0.1/include
-internal-isystem /usr/x86_64-pc-cygwin/include
-internal-isystem /usr/include
-internal-isystem /usr/include/w32api ...
ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include/c++"
ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include/c++/x86_64-pc-cygwin"
ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include/c++/backward"
ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include/c++/11"
ignoring nonexistent directory 
"/usr/x86_64-pc-cygwin/include/c++/11/x86_64-pc-cygwin"
ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include/c++/11/backward"
ignoring nonexistent directory "/usr/include/c++/11"
ignoring nonexistent directory "/usr/include/c++/11/x86_64-pc-cygwin"
ignoring nonexistent directory "/usr/include/c++/11/backward"
ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include"
ignoring duplicate directory "/usr/lib/clang/8.0.1/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++
  /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin
  /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/backward
  /usr/lib/clang/8.0.1/include
  /usr/local/include
  /usr/include
  /usr/include/w32api
End of search list.

You may want to try to override the built in includes from -internal-isystem 
with those mentioned above but not built in.

I have no idea why both compilers would include w32api headers as if they were 
building Mingw cross compilers!

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

-- 
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