public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* iostream doesn't work (clang++)
@ 2023-07-04 16:48 ggl329
  2023-07-04 18:51 ` Mark Geisert
  2023-07-05  3:06 ` Mark Geisert
  0 siblings, 2 replies; 11+ messages in thread
From: ggl329 @ 2023-07-04 16:48 UTC (permalink / raw)
  To: cygwin

Hi,

clang++ fails with iostream.
Does it go well in your environment?
# I noticed that clang is orphaned. clang requires a maintainer?


$ cat sample.cc
#include <iostream>
int main()
{
     std::cout << "Hello World.\n";
     return 0;
}

$ g++ sample.cc
$ ./a
Hello World.

$ clang++ sample.cc
In file included from sample.cc:1:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iostream:39:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ostream:38:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ios:42:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35:
In file included from /usr/include/pthread.h:11:
In file included from /usr/include/sys/types.h:221:
In file included from /usr/include/sys/_pthreadtypes.h:12:
/usr/include/sys/cpuset.h:45:24: error: use of undeclared identifier '__builtin_malloc'; did you mean
       '__builtin_alloca'?
   return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
                        ^
/usr/include/sys/cpuset.h:45:24: note: '__builtin_alloca' declared here
/usr/include/sys/cpuset.h:52:3: error: use of undeclared identifier '__builtin_free'
   __builtin_free (set);
   ^
2 errors generated.


Package version information which may be related.

Cygwin Package Information
Package              Version
binutils             2.40-1
clang                8.0.1-1
compiler-rt          8.0.1-1
cygwin               3.4.7-1
cygwin-devel         3.4.7-1
gcc-core             11.4.0-1
gcc-g++              11.4.0-1
libc++-devel         8.0.1-1
libc++1              8.0.1-1
libc++abi-devel      8.0.1-1
libc++abi1           8.0.1-1
libclang-devel       8.0.1-1
libclang8            8.0.1-1
libllvm-devel        8.0.1-1
libllvm8             8.0.1-1
libpolly-devel       8.0.1-1
libpolly8            8.0.1-1
libstdc++6           11.4.0-1
libunwind-devel      8.0.1-1
libunwind1           8.0.1-1
llvm                 8.0.1-1

-- 
   ggl329

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: iostream doesn't work (clang++)
  2023-07-04 16:48 iostream doesn't work (clang++) ggl329
@ 2023-07-04 18:51 ` Mark Geisert
  2023-07-05  3:06 ` Mark Geisert
  1 sibling, 0 replies; 11+ messages in thread
From: Mark Geisert @ 2023-07-04 18:51 UTC (permalink / raw)
  To: cygwin

Hi there,

ggl329 via Cygwin wrote:
> Hi,
> 
> clang++ fails with iostream.
> Does it go well in your environment?
> # I noticed that clang is orphaned. clang requires a maintainer?
> 
> 
> $ cat sample.cc
> #include <iostream>
> int main()
> {
>      std::cout << "Hello World.\n";
>      return 0;
> }
> 
> $ g++ sample.cc
> $ ./a
> Hello World.
> 
> $ clang++ sample.cc
> In file included from sample.cc:1:
> In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iostream:39:
> In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ostream:38:
> In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ios:42:
> In file included from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39:
> In file included from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35:
> In file included from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148:
> In file included from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35:
> In file included from /usr/include/pthread.h:11:
> In file included from /usr/include/sys/types.h:221:
> In file included from /usr/include/sys/_pthreadtypes.h:12:
> /usr/include/sys/cpuset.h:45:24: error: use of undeclared identifier 
> '__builtin_malloc'; did you mean
>        '__builtin_alloca'?
>    return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
>                         ^
> /usr/include/sys/cpuset.h:45:24: note: '__builtin_alloca' declared here
> /usr/include/sys/cpuset.h:52:3: error: use of undeclared identifier '__builtin_free'
>    __builtin_free (set);
>    ^
> 2 errors generated.
[...]

That's not a problem with <iostream>, but with <sys/cpuset.h>.  It did not 
anticipate being compiled with clang.  I will submit a patch.
Thanks for the report,

..mark

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: iostream doesn't work (clang++)
  2023-07-04 16:48 iostream doesn't work (clang++) ggl329
  2023-07-04 18:51 ` Mark Geisert
@ 2023-07-05  3:06 ` Mark Geisert
  2023-07-05 15:54   ` ggl329
  1 sibling, 1 reply; 11+ messages in thread
From: Mark Geisert @ 2023-07-05  3:06 UTC (permalink / raw)
  To: cygwin

Hi again,

ggl329 via Cygwin wrote:
> Hi,
> 
> clang++ fails with iostream.
> Does it go well in your environment?
> # I noticed that clang is orphaned. clang requires a maintainer?

It would indeed be nice to have a clang maintainer.  Until that happens various 
other folks might be able to assist if their schedules allow.

> $ cat sample.cc
> #include <iostream>
> int main()
> {
>      std::cout << "Hello World.\n";
>      return 0;
> }
> 
> $ g++ sample.cc
> $ ./a
> Hello World.
> 
> $ clang++ sample.cc
> In file included from sample.cc:1:
> In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iostream:39:
> In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ostream:38:
> In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ios:42:
> In file included from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39:
> In file included from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35:
> In file included from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148:
> In file included from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35:
> In file included from /usr/include/pthread.h:11:
> In file included from /usr/include/sys/types.h:221:
> In file included from /usr/include/sys/_pthreadtypes.h:12:
> /usr/include/sys/cpuset.h:45:24: error: use of undeclared identifier 
> '__builtin_malloc'; did you mean
>        '__builtin_alloca'?
>    return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
>                         ^
> /usr/include/sys/cpuset.h:45:24: note: '__builtin_alloca' declared here
> /usr/include/sys/cpuset.h:52:3: error: use of undeclared identifier '__builtin_free'
>    __builtin_free (set);
>    ^
> 2 errors generated.
> 
> 
> Package version information which may be related.
> 
> Cygwin Package Information
> Package              Version
> binutils             2.40-1
> clang                8.0.1-1
> compiler-rt          8.0.1-1
> cygwin               3.4.7-1
> cygwin-devel         3.4.7-1
> gcc-core             11.4.0-1
> gcc-g++              11.4.0-1
> libc++-devel         8.0.1-1
> libc++1              8.0.1-1
> libc++abi-devel      8.0.1-1
> libc++abi1           8.0.1-1
> libclang-devel       8.0.1-1
> libclang8            8.0.1-1
> libllvm-devel        8.0.1-1
> libllvm8             8.0.1-1
> libpolly-devel       8.0.1-1
> libpolly8            8.0.1-1
> libstdc++6           11.4.0-1
> libunwind-devel      8.0.1-1
> libunwind1           8.0.1-1
> llvm                 8.0.1-1

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.

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.

My list of possibly related package versions looks very similar to yours:
binutils           2.40-1
clang              8.0.1-1
compiler-rt        8.0.1-1
cygwin             3.4.7-1
cygwin-devel       3.4.7-1
gcc-core           11.4.0-1
gcc-g++            11.4.0-1
libatomic1         11.4.0-1
libc++-devel       8.0.1-1
libc++1            8.0.1-1
libc++abi-devel    8.0.1-1
libc++abi1         8.0.1-1
libclang-devel     8.0.1-1
libclang8          8.0.1-1
libgcc1            11.4.0-1
libllvm-devel      8.0.1-1
libllvm8           8.0.1-1
libpolly-devel     8.0.1-1
libpolly8          8.0.1-1
libquadmath0       11.4.0-1
libstdc++6         11.4.0-1
libunwind-devel    8.0.1-1
libunwind1         8.0.1-1
llvm               8.0.1-1

I'm not a clang user so there might be something fundamentally wrong with my setup 
that I don't see.  Also, do you have a CFLAGS or other environment string(s) that 
would possibly be passed to clang as it would to gcc?  Has "clang++" been aliased 
to something else, perhaps passing options that way?  Also, do you happen to have 
any of the boost libraries installed?

I'm willing to patch the reported error but I'd like to first make sure it is 
legitimate for clang to have gone down the reported include path through what look 
like gcc-related include files.

..mark

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: iostream doesn't work (clang++)
  2023-07-05  3:06 ` Mark Geisert
@ 2023-07-05 15:54   ` ggl329
  2023-07-05 23:08     ` Brian Inglis
  2023-07-13  5:52     ` Mark Geisert
  0 siblings, 2 replies; 11+ messages in thread
From: ggl329 @ 2023-07-05 15:54 UTC (permalink / raw)
  To: cygwin

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



$ clang++ sample.cc --verbose
clang version 8.0.1 (tags/RELEASE_801/final)
Target: x86_64-unknown-windows-cygnus
Thread model: posix
InstalledDir: /usr/bin
  "/usr/bin/clang-8" -cc1 -triple x86_64-unknown-windows-cygnus -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name sample.cc -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -v -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 -fdeprecated-macro -fdebug-compilation-dir /home/ggl329/tmp -ferror-limit 19 -fmessage-length 120 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fseh-exceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/sample-76ab2a.o -x c++ sample.cc -faddrsig
clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target x86_64-unknown-cygwin
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/local/include"
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/include
  /usr/include/w32api
End of search list.
In file included from sample.cc:1:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iostream:39:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ostream:38:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ios:42:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35:
In file included from /usr/include/pthread.h:11:
In file included from /usr/include/sys/types.h:221:
In file included from /usr/include/sys/_pthreadtypes.h:12:
/usr/include/sys/cpuset.h:45:24: error: use of undeclared identifier '__builtin_malloc'; did you mean
       '__builtin_alloca'?
   return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
                        ^
/usr/include/sys/cpuset.h:45:24: note: '__builtin_alloca' declared here
/usr/include/sys/cpuset.h:52:3: error: use of undeclared identifier '__builtin_free'
   __builtin_free (set);
   ^
2 errors generated.



> My list of possibly related package versions looks very similar to yours:

In my environment, all the packages and versions you listed are installed.

> I'm not a clang user so there might be something fundamentally wrong with
> my setup that I don't see.  Also, do you have a CFLAGS or other environment
> string(s) that would possibly be passed to clang as it would to gcc?
> Has "clang++" been aliased to something else, perhaps passing options
> that way?  Also, do you happen to have any of the boost libraries installed?

I also use gcc mainly. I use clang just for bug check and coding completion.
So, I'm not familiar with clang's behavior either.
CFLAGS, CXXFLAGS and such other environment variables are not set.
/usr/bin/clang++ is linked to clang-8.exe, and /usr/bin/clang-8.exe is
executed as in the log shown above.
Only libboost_regex1.66 is installed from boost.

$ printenv | grep include
(no output)
$ printenv | grep -i flag
(no output)
$ type clang++
clang++ is /usr/bin/clang++
$ ls -o /usr/bin/clang++
lrwxrwxrwx 1 root 11 Jan  8 16:08 /usr/bin/clang++ -> clang-8.exe
$ cygcheck -dc | grep boost
libboost_regex1.66                      1.66.0-1


Thanks,


    ggl329

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: iostream doesn't work (clang++)
  2023-07-05 15:54   ` ggl329
@ 2023-07-05 23:08     ` Brian Inglis
  2023-07-07  8:01       ` Mark Geisert
  2023-07-07 15:48       ` Jon Turney
  2023-07-13  5:52     ` Mark Geisert
  1 sibling, 2 replies; 11+ messages in thread
From: Brian Inglis @ 2023-07-05 23:08 UTC (permalink / raw)
  To: cygwin; +Cc: ggl329

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: iostream doesn't work (clang++)
  2023-07-05 23:08     ` Brian Inglis
@ 2023-07-07  8:01       ` Mark Geisert
  2023-07-07 15:48       ` Jon Turney
  1 sibling, 0 replies; 11+ messages in thread
From: Mark Geisert @ 2023-07-07  8:01 UTC (permalink / raw)
  To: cygwin

Brian Inglis via Cygwin wrote:
> 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!

Thanks very much Brian for this overview.  I'd rather not delay a fix for the OP 
any longer, so I have submitted a patch for the reported issue.  If it turns out 
that, with the patch, the OP can successfully compile and build his testcase, we 
may be done.

If not, somebody (TM) may have to dig into what's been discovered and how to 
remedy it.  Comparing Cygwin's clang/clang++ installation with some Linux's 
installation might be helpful.  I have some other ideas but I can't commit time to 
following them up ATM.
Thanks all,

..mark

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: iostream doesn't work (clang++)
  2023-07-05 23:08     ` Brian Inglis
  2023-07-07  8:01       ` Mark Geisert
@ 2023-07-07 15:48       ` Jon Turney
  2023-07-07 18:18         ` gs-cygwin.com
  1 sibling, 1 reply; 11+ messages in thread
From: Jon Turney @ 2023-07-07 15:48 UTC (permalink / raw)
  To: Brian Inglis via Cygwin, The Cygwin Mailing List

On 06/07/2023 00:08, Brian Inglis via Cygwin wrote:
> 
> I have no idea why both compilers would include w32api headers as if 
> they were building Mingw cross compilers!

You are allowed to use the Win32 API in Cygwin programs (with some caveats).

Various Cygwin utilities which interface with the Windows environment 
rely on this.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: iostream doesn't work (clang++)
  2023-07-07 15:48       ` Jon Turney
@ 2023-07-07 18:18         ` gs-cygwin.com
  2023-07-08  9:12           ` Jon Turney
  0 siblings, 1 reply; 11+ messages in thread
From: gs-cygwin.com @ 2023-07-07 18:18 UTC (permalink / raw)
  To: Jon Turney; +Cc: cygwin

On Fri, Jul 07, 2023 at 04:48:08PM +0100, Jon Turney via Cygwin wrote:
> On 06/07/2023 00:08, Brian Inglis via Cygwin wrote:
> > 
> > I have no idea why both compilers would include w32api headers as if
> > they were building Mingw cross compilers!
> 
> You are allowed to use the Win32 API in Cygwin programs (with some caveats).

Interesting.

Is there some collected wisdom somewhere to which you could point me?
(specifically the caveats)

My code runs under cygwin and I more recently ported it to native
Windows.  Windows is not POSIX, but does provide a hodge-podge of
functions named the same as POSIX function, sometimes with slightly
different behavior and sometimes with slightly different function
signatures (!).

For performance under cygwin, it is desirable to use Windows-native API
when the cygwin layer is a simple translation compatibility layer from
POSIX to Windows API.  However, Windows is not simple, and seemingly
never invested in creating a stable and functional set of POSIX-like
interfaces, and is one of the reasons cygwin is so useful to bridge that
gapping chasm.

Cheers, Glenn

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: iostream doesn't work (clang++)
  2023-07-07 18:18         ` gs-cygwin.com
@ 2023-07-08  9:12           ` Jon Turney
  0 siblings, 0 replies; 11+ messages in thread
From: Jon Turney @ 2023-07-08  9:12 UTC (permalink / raw)
  To: gs-cygwin.com, The Cygwin Mailing List

On 07/07/2023 19:18, gs-cygwin.com--- via Cygwin wrote:
> On Fri, Jul 07, 2023 at 04:48:08PM +0100, Jon Turney via Cygwin wrote:
>> On 06/07/2023 00:08, Brian Inglis via Cygwin wrote:
>>>
>>> I have no idea why both compilers would include w32api headers as if
>>> they were building Mingw cross compilers!
>>
>> You are allowed to use the Win32 API in Cygwin programs (with some caveats).
> 
> Interesting.
> 
> Is there some collected wisdom somewhere to which you could point me?
> (specifically the caveats)

The caveats are mentioned in the Cygwin UG. See:

https://cygwin.com/cygwin-ug-net/setup-env.html#setup-env-win32
https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api
https://cygwin.com/cygwin-ug-net/programming.html#gcc-64

One additional caveat I am aware of which possibly should be documented 
there, but isn't, is basically "Don't try to use DllMain() in a Cygwin 
DLL, unless you know exactly what you are doing".


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: iostream doesn't work (clang++)
  2023-07-05 15:54   ` ggl329
  2023-07-05 23:08     ` Brian Inglis
@ 2023-07-13  5:52     ` Mark Geisert
  2023-07-13 16:11       ` ggl329
  1 sibling, 1 reply; 11+ messages in thread
From: Mark Geisert @ 2023-07-13  5:52 UTC (permalink / raw)
  To: cygwin

Hi once again,

ggl329 via Cygwin wrote:
> 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.
[... useful info elided from this quote ...]

I was able to build a working clang/clang++ environment and then reproduce your 
report.  A potential solution was discussed on the cygwin-patches mailing list.

Just a quick note to say the root cause has been fixed; the next version of the 
Cygwin DLL (3.4.8) will include the fix.  If you need the fix urgently you can 
find a replacement for your /usr/include/sys/cpuset.h at
https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/include/sys/cpuset.h
I would suggest moving (with 'mv') your existing file out of the way but keeping 
it around in case of any mishap getting the replacement.

Thanks again for reporting this issue,

..mark


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: iostream doesn't work (clang++)
  2023-07-13  5:52     ` Mark Geisert
@ 2023-07-13 16:11       ` ggl329
  0 siblings, 0 replies; 11+ messages in thread
From: ggl329 @ 2023-07-13 16:11 UTC (permalink / raw)
  To: cygwin

Hi Mark,

On 2023/07/13 14:52, Mark Geisert via Cygwin wrote:
> Just a quick note to say the root cause has been fixed; the next version of the Cygwin DLL (3.4.8) will include the fix.  If you need the fix urgently you can find a replacement for your /usr/include/sys/cpuset.h at
> https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/include/sys/cpuset.h

Thanks for taking time.
It works again in my environment.


The followings is just for information.
(It may not be necessary to address the issues.)

1.
clang++ complains that "-liconv" doesn't exist when compiling the "hello world".
By installing libiconv-devel, I successfully made it.
(g++ doesn't require "-liconv".)

2.
llvm depends on python-pygments and python-yaml, which pull python27 in.
But python27 has already been withdrawn. Newcomers may get confused.

-- 
   ggl329


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2023-07-13 16:11 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-04 16:48 iostream doesn't work (clang++) ggl329
2023-07-04 18:51 ` Mark Geisert
2023-07-05  3:06 ` Mark Geisert
2023-07-05 15:54   ` ggl329
2023-07-05 23:08     ` Brian Inglis
2023-07-07  8:01       ` Mark Geisert
2023-07-07 15:48       ` Jon Turney
2023-07-07 18:18         ` gs-cygwin.com
2023-07-08  9:12           ` Jon Turney
2023-07-13  5:52     ` Mark Geisert
2023-07-13 16:11       ` ggl329

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).