[Bug c++/104157] New: libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[Bug c++/104157] New: libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

            Bug ID: 104157
           Summary: libc++ does not work properly with x86_64-w64-mingw32
                    host, but works fine with x86_64-linux-gnu host
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

d:\x86_64-windows-gnu\aarch64-linux-android\aarch64-linux-android\include\c++\v1\cstddef:44:25:
error: no include path in which to search for stddef.h
   44 | #include_next <stddef.h>
      |                         ^
d:\x86_64-windows-gnu\aarch64-linux-android\aarch64-linux-android\include\c++\v1\cstddef:49:9:
error: 'ptrdiff_t' has not been declared in '::'
   49 | using ::ptrdiff_t _LIBCPP_USING_IF_EXISTS;
      |         ^~~~~~~~~
d:\x86_64-windows-gnu\aarch64-linux-android\aarch64-linux-android\include\c++\v1\cstddef:50:9:
error: 'size_t' has not been declared in '::'
   50 | using ::size_t _LIBCPP_USING_IF_EXISTS;
      |         ^~~~~~
d:\x86_64-windows-gnu\aarch64-linux-android\aarch64-linux-android\include\c++\v1\cstddef:53:9:
error: 'max_align_t' has not been declared in '::'


It cannot find the include path correctly for libc++ when host is windows.

D:\hg\fast_io\examples\0001.helloworld>aarch64-linux-android-g++ -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-android-g++
COLLECT_LTO_WRAPPER=d:/x86_64-windows-gnu/aarch64-linux-android/bin/../libexec/gcc/aarch64-linux-android/12.0.1/lto-wrapper.exe
Target: aarch64-linux-android
Configured with: ../../../../gcc/configure --disable-nls --disable-werror
--target=aarch64-linux-android
--prefix=/home/cqwrteur/toolchains/gnu/x86_64-w64-mingw32/aarch64-linux-android
--enable-languages=c,c++ --disable-libstdcxx-verbose --disable-multilib
--with-gxx-libcxx-include-dir=/home/cqwrteur/toolchains/gnu/x86_64-w64-mingw32/aarch64-linux-android/aarch64-linux-android/include/c++/v1
--host=x86_64-w64-mingw32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220121 (experimental) (GCC)

[Bug c++/104157] libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #1 from cqwrteur <unlvsur at live dot com> ---
D:\hg\fast_io\examples\0001.helloworld>aarch64-linux-android-g++ -o helloworld
helloworld.cc -Ofast -std=c++23 -s -flto -I../../include -Wall -stdlib=libc++
-std=c++2b

[Bug c++/104157] libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2022-01-21

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Where is the target stddef.h located?
Can you add -v while compiling and provide the full output?

[Bug c++/104157] libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #3 from cqwrteur <unlvsur at live dot com> ---
Created attachment 52253
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52253&action=edit
error message on windows

[Bug c++/104157] libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
inside d:\x86_64-windows-gnu\aarch64-linux-android can you find all files
called stddef.h and print their path?

[Bug c++/104157] libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #5 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Pinski from comment #4)
> inside d:\x86_64-windows-gnu\aarch64-linux-android can you find all files
> called stddef.h and print their path?

D:\x86_64-windows-gnu\aarch64-linux-android\aarch64-linux-android\include\c++\v1
D:\x86_64-windows-gnu\aarch64-linux-android\aarch64-linux-android\include\linux
D:\x86_64-windows-gnu\aarch64-linux-android\lib\gcc\aarch64-linux-android\12.0.1\include

[Bug c++/104157] libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
You say it works with the host as linux, can you show the output of -v while
compiling?

[Bug c++/104157] libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
By the way the order looks wrong:


d:\x86_64-windows-gnu\aarch64-linux-android\bin\../lib/gcc/aarch64-linux-android/12.0.1/include

d:\x86_64-windows-gnu\aarch64-linux-android\bin\../lib/gcc/aarch64-linux-android/12.0.1/include-fixed

d:\x86_64-windows-gnu\aarch64-linux-android\bin\../lib/gcc/aarch64-linux-android/12.0.1/../../../../aarch64-linux-android/include

d:/x86_64-windows-gnu/aarch64-linux-android/lib/gcc/../../aarch64-linux-android/include/c++/v1

C++ includes should be first. really

[Bug c++/104157] libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #8 from cqwrteur <unlvsur at live dot com> ---
Created attachment 52254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52254&action=edit
result from linux

Yes on linux include/v1/c++ goes first.


BTW Can we just make 

--with-gxx-libcxx-include-dir=$PREFIX/$TARGET/include/c++/v1 by default unless
users set it?
It is annoying to set this every time for configuring. It should by default the
same as libstdc++

[Bug c++/104157] libc++ does not work properly with x86_64-w64-mingw32 host, but works fine with x86_64-linux-gnu host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #9 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Pinski from comment #6)
> You say it works with the host as linux, can you show the output of -v while
> compiling?

Same issue happens with x86_64-ubuntu-linux-gnu target, x86_64-w64-mingw32 host
too.

Looks like we have some issues dealing with this on windows at the compiler
side.

[Bug c++/104157] -std=libc++ does not with cross compilers and moving the install around (places the include path last)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED
            Summary|libc++ does not work        |-std=libc++ does not with
                   |properly with               |cross compilers and moving
                   |x86_64-w64-mingw32 host,    |the install around (places
                   |but works fine with         |the include path last)
                   |x86_64-linux-gnu host       |
     Ever confirmed|1                           |0

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #8)
> Created attachment 52254 [details]
> result from linux
> 
> Yes on linux include/v1/c++ goes first.

The main difference is the addition of:
-iprefix
d:\x86_64-windows-gnu\aarch64-linux-android\bin\../lib/gcc/aarch64-linux-android/12.0.1/

The problem is somewhere in add_standard_paths 


My guess is if you move the install directory for the linux case, the problem
on Linux will show up too.

[Bug c++/104157] -std=libc++ does not with cross compilers and moving the install around (places the include path last)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Somehow add_standard_paths is doing the wrong thing when -iprefix is applied
but I have no idea how or why. This definitely needs to be fixed but it is a
low priority as -std=libc++ is not used that much, especially with
non-sysrooted cross compilers.

[Bug c++/104157] -std=libc++ does not with cross compilers and moving the install around (places the include path last)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #12 from cqwrteur <unlvsur at live dot com> ---
well. plus canadian cross back compiler From windows to linux.
probably only i cross compile Linux programs on windows.(several other people
downloaded my toolchains.)


Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: pinskia at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Friday, January 21, 2022 4:20:19 AM
To: unlvsur@live.com <unlvsur@live.com>
Subject: [Bug c++/104157] -std=libc++ does not with cross compilers and moving
the install around (places the include path last)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Somehow add_standard_paths is doing the wrong thing when -iprefix is applied
but I have no idea how or why. This definitely needs to be fixed but it is a
low priority as -std=libc++ is not used that much, especially with
non-sysrooted cross compilers.

--
You are receiving this mail because:
You reported the bug.
You are on the CC list for the bug.

[Bug c++/104157] -std=libc++ does not with cross compilers and moving the install around (places the include path last)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104157

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #12)
> well. plus canadian cross back compiler From windows to linux.
> probably only i cross compile Linux programs on windows.(several other
> people downloaded my toolchains.)

Yes but hardly anyone uses -std=libc++ in general :). And using non-sysroot
these days is not really supported and for good reasons.