Open Andarwinux opened 1 month ago
Can you isolate the individual source file from the build, triggering the issue? And can you reduce the included headers from there, to only including libc++ headers, triggering the issue? I would guess that there's some either command line or source level define somewhere that triggers this. Not saying it isn't a libc++ and/or mingw bug though, but we'd need a smaller reproduction to be able to say for sure.
Can you isolate the individual source file from the build, triggering the issue? And can you reduce the included headers from there, to only including libc++ headers, triggering the issue? I would guess that there's some either command line or source level define somewhere that triggers this. Not saying it isn't a libc++ and/or mingw bug though, but we'd need a smaller reproduction to be able to say for sure.
I found a smaller reproduction test.zip
[arch@wsl test]$ x86_64-w64-mingw32-clang++ -c -I -DHAVE_WINSOCK2_H -DHAVE_WS2TCPIP_H -DHAVE_INTTYPES_H SSHSession.cc
In file included from SSHSession.cc:35:
In file included from ./SSHSession.h:39:
In file included from ./a2netcompat.h:94:
In file included from /home/arch/workspace/toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/string:648:
In file included from /home/arch/workspace/toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/string_view:958:
In file included from /home/arch/workspace/toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/algorithm:1851:
In file included from /home/arch/workspace/toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/__algorithm/for_each.h:16:
In file included from /home/arch/workspace/toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/__ranges/movable_box.h:21:
In file included from /home/arch/workspace/toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/optional:1297:
In file included from /home/arch/workspace/toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/memory:944:
In file included from /home/arch/workspace/toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/__memory/inout_ptr.h:16:
In file included from /home/arch/workspace/toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/__memory/shared_ptr.h:32:
/home/arch/workspace/toolchain/llvm-mingw/x86_64-w64-mingw32/include/c++/v1/__memory/unique_ptr.h:379:88: error: use of undeclared identifier 'SIZE_MAX'
379 | _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR __unique_ptr_array_bounds_stored() : __size_(SIZE_MAX) {}
| ^
1 error generated.
Ok, I've reproed that. But when I try the same, I'm also getting another error, which also is present when building with a release:
In file included from SSHSession.cc:35:
In file included from ./SSHSession.h:39:
./a2netcompat.h:117:3: error: unknown type name 'sockaddr_in6'; did you mean 'sockaddr_in'?
117 | sockaddr_in6 in6;
| ^~~~~~~~~~~~
| sockaddr_in
/home/martin/llvm-mingw-20240917-ucrt-ubuntu-20.04-x86_64/x86_64-w64-mingw32/include/psdk_inc/_ip_types.h:75:8: note: 'sockaddr_in' declared here
75 | struct sockaddr_in {
| ^
In file included from SSHSession.cc:35:
In file included from ./SSHSession.h:39:
./a2netcompat.h:123:3: error: unknown type name 'socklen_t'
123 | socklen_t suLength;
| ^
2 errors generated.
I presume that's unrelated to the libcxx header issue anyway.
I've reduced it down to a much smaller issue, and I would say that this isn't really the fault of libcxx. A minimal reproducer of the issue is this:
#include <limits.h>
#include <stdint.h>
#undef SIZE_MAX
#include <string>
Previously, <string>
wouldn't include anything that needs SIZE_MAX
, but after the linked libc++ commit, it now does. Both <limits.h>
and <stdint.h>
can provide a definition of SIZE_MAX
if it isn't already defined, but by including both of them before we do #undef SIZE_MAX
, we essentially make sure that we won't be getting a new definition of the type again.
When you look at it in this form, it obviously seems quite absurd, but this is that the attached example boils down to. See your gai_strerror.h
which contains this bit:
#ifdef __MINGW32__
# undef SIZE_MAX
#endif // __MINGW32__
And all the other headers around end up having the same effect as in the reduced example above.
I've reduced it down to a much smaller issue, and I would say that this isn't really the fault of libcxx. A minimal reproducer of the issue is this:
#include <limits.h> #include <stdint.h> #undef SIZE_MAX #include <string>
I guess it could, maybe, be argued that libcxx internally shouldn't be using SIZE_MAX
, but should use __SIZE_MAX__
instead though.
I've reduced it down to a much smaller issue, and I would say that this isn't really the fault of libcxx. A minimal reproducer of the issue is this:
#include <limits.h> #include <stdint.h> #undef SIZE_MAX #include <string>
Previously,
<string>
wouldn't include anything that needsSIZE_MAX
, but after the linked libc++ commit, it now does. Both<limits.h>
and<stdint.h>
can provide a definition ofSIZE_MAX
if it isn't already defined, but by including both of them before we do#undef SIZE_MAX
, we essentially make sure that we won't be getting a new definition of the type again.When you look at it in this form, it obviously seems quite absurd, but this is that the attached example boils down to. See your
gai_strerror.h
which contains this bit:#ifdef __MINGW32__ # undef SIZE_MAX #endif // __MINGW32__
And all the other headers around end up having the same effect as in the reduced example above.
I will try to fix this in aria2 🤣.
I'm sorry I couldn't find a smaller reproduction of this
This happens in llvm-mingw nightly, and is caused by https://github.com/llvm/llvm-project/commit/18df9d23ea390eaa50b41f3083a42f700a2b0e39 to be exact, if I replace
SIZE_MAX
with__SIZE_MAX__
it doesn't cause a problem, but that commit itself doesn't look wrong. I don't know whySIZE_MAX
isn't defined, cstdint should end up include stdint.h from mingw.