Bug#1057838: clang-17: c++ include dir from sysroot unexpectedly in include paths when in wasm c mode
On 15-Dec-23 3:24 PM, Faidon Liambotis wrote: Thanks, Sylvestre for the Cc and Israel for the bug report! On Fri, Dec 15, 2023 at 02:00:55PM +0100, Sylvestre Ledru wrote: The above lines are adding c++ include paths in the method (WebAssembly::AddClangSystemIncludeArgs) for adding only system/c include paths. I think the c++ include paths should only be added in the methods for adding libc++ (WebAssembly::addLibCxxIncludePaths) or libstdc++ (WebAssembly::addLibStdCXXIncludePaths) include paths. Israel, I can confirm that your interpetation is correct :) Can you confirm whether you're experiencing the same issue with clang-16? I just tested with clang-16 and it is working well \o/. Thanks for the help Sylvestre, Faidon. OpenPGP_0x3679ECB87B7CEC0C.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057838: clang-17: c++ include dir from sysroot unexpectedly in include paths when in wasm c mode
Thanks, Sylvestre for the Cc and Israel for the bug report! On Fri, Dec 15, 2023 at 02:00:55PM +0100, Sylvestre Ledru wrote: > > The above lines are adding c++ include paths in the > > method (WebAssembly::AddClangSystemIncludeArgs) > > for adding only system/c include paths. > > I think the c++ include paths should only be added in the methods for > > adding > > libc++ (WebAssembly::addLibCxxIncludePaths) or libstdc++ > > (WebAssembly::addLibStdCXXIncludePaths) include > > paths. Israel, I can confirm that your interpetation is correct :) Can you confirm whether you're experiencing the same issue with clang-16? Sylvestre, from a cursory look I think the patch that I recently provided, the one that you applied and was included in the src:llvm-toolchain-16 1:16.0.6-19 upload, has not been carried over to at least the 17 branch. I think this will probably fix this bug as well. Thanks, Faidon
Bug#1057838: clang-17: c++ include dir from sysroot unexpectedly in include paths when in wasm c mode
+Faidon
Le 15/12/2023 à 13:15, Israel Galadima a écrit :
Dear Maintainers,
I have looked further into this and I think these lines in the patch
file at debian/patches/wasm/wasm-sysroot-usr.diff
are responsible.
40 + if (!getDriver().SysRoot.empty()) {
41 + // Second add the generic one.
42 + addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" +
Version);
43 + // Third the backward one.
44 + addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" +
Version + "/backward");
45 + }
The above lines are adding c++ include paths in the
method (WebAssembly::AddClangSystemIncludeArgs)
for adding only system/c include paths.
I think the c++ include paths should only be added in the methods for
adding
libc++ (WebAssembly::addLibCxxIncludePaths) or libstdc++
(WebAssembly::addLibStdCXXIncludePaths) include
paths.
Some context on why I need this fixed. I'm updating emscripten in
Debian and need to
provide pre-compiled libraries to the end user. However, when
compiling c files in compiler-rt
that include stdatomic.h, an issue arises. The system's stdatomic.h
file uses an include_next
to select any other stdatomic.h it finds in the include paths, and
since there's another stdatomic.h [1]
in the c++ include path of the emscripten sysroot, it gets selected.
Ideally, the other stdatomic.h
shouldn't be seen, but when compiling c files, clang-17 wrongly adds
the c++ include directory from
the emscripten sysroot to the include paths which causes the conflict.
1.
https://github.com/emscripten-core/emscripten/blob/main/system/lib/libcxx/include/stdatomic.h
___
Pkg-llvm-team mailing list
pkg-llvm-t...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team
Bug#1057838: clang-17: c++ include dir from sysroot unexpectedly in include paths when in wasm c mode
Dear Maintainers,
I have looked further into this and I think these lines in the patch
file at debian/patches/wasm/wasm-sysroot-usr.diff
are responsible.
40 + if (!getDriver().SysRoot.empty()) {
41 + // Second add the generic one.
42 + addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" +
Version);
43 + // Third the backward one.
44 + addSystemInclude(DriverArgs, CC1Args, LibPath + "/c++/" +
Version + "/backward");
45 + }
The above lines are adding c++ include paths in the
method (WebAssembly::AddClangSystemIncludeArgs)
for adding only system/c include paths.
I think the c++ include paths should only be added in the methods for adding
libc++ (WebAssembly::addLibCxxIncludePaths) or libstdc++
(WebAssembly::addLibStdCXXIncludePaths) include
paths.
Some context on why I need this fixed. I'm updating emscripten in Debian
and need to
provide pre-compiled libraries to the end user. However, when compiling
c files in compiler-rt
that include stdatomic.h, an issue arises. The system's stdatomic.h file
uses an include_next
to select any other stdatomic.h it finds in the include paths, and since
there's another stdatomic.h [1]
in the c++ include path of the emscripten sysroot, it gets selected.
Ideally, the other stdatomic.h
shouldn't be seen, but when compiling c files, clang-17 wrongly adds the
c++ include directory from
the emscripten sysroot to the include paths which causes the conflict.
1.
https://github.com/emscripten-core/emscripten/blob/main/system/lib/libcxx/include/stdatomic.h
OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1057838: clang-17: c++ include dir from sysroot unexpectedly in include paths when in wasm c mode
Package: clang-17 Version: 1:17.0.6-1 Severity: important X-Debbugs-Cc: izzygalad...@gmail.com Dear Maintainer, When I checked the include paths for clang-17 in c mode with wasm target and sysroot, I saw the c++ include dir from the sysroot among the include paths. $ clang-17 -target wasm32-unknown-emscripten --sysroot=/home/izzygala/node-packaging/emscripten/emscripten/cache/sysroot -E - -v Debian clang version 17.0.6 (1) Target: wasm32-unknown-emscripten ... ... ... ignoring nonexistent directory "/home/izzygala/node-packaging/emscripten/emscripten/cache/sysroot/local/include/wasm32-emscripten" ignoring nonexistent directory "/home/izzygala/node-packaging/emscripten/emscripten/cache/sysroot/local/include" ignoring nonexistent directory "/home/izzygala/node-packaging/emscripten/emscripten/cache/sysroot/include/wasm32-emscripten" ignoring nonexistent directory "/home/izzygala/node-packaging/emscripten/emscripten/cache/sysroot/include/c++/v1/backward" # I did not expect this to be here #include "..." search starts here: #include <...> search starts here: /usr/lib/llvm-17/lib/clang/17/include /home/izzygala/node-packaging/emscripten/emscripten/cache/sysroot/include/c++/v1 # I did not expect this to be here /home/izzygala/node-packaging/emscripten/emscripten/cache/sysroot/include End of search list. I didn't expect to see /home/izzygala/node-packaging/emscripten/emscripten/cache/sysroot/include/c++/v1 in the include paths. I didn't expect clang to attempt to add /home/izzygala/node-packaging/emscripten/emscripten/cache/sysroot/include/c++/v1/backward to the include paths. I tried the same setup with a pre-built clang binary on Windows and it does not add the c++ include dir from the sysroot to the include paths for c mode with wasm target and sysroot. PS C:\Users\Isreal Galadima\Documents\Code\emscripten> clang -target wasm32-unknown-emscripten --sysroot="C:/Users/Isreal Galadima/Documents/Code/emscripten/cache/sysroot" -E - -v clang version 17.0.6 Target: wasm32-unknown-emscripten Thread model: posix ... ... ... ignoring nonexistent directory "C:/Users/Isreal Galadima/Documents/Code/emscripten/cache/sysroot/include/wasm32-emscripten" #include "..." search starts here: #include <...> search starts here: C:\Program Files\LLVM\lib\clang\17\include C:/Users/Isreal Galadima/Documents/Code/emscripten/cache/sysroot/include End of search list. I think this [1] patch on Salsa may be the cause. Thanks. 1. https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/blob/17/debian/patches/wasm/wasm-sysroot-usr.diff -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.123.1-microsoft-standard-WSL2 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages clang-17 depends on: ii binutils2.41.50.20231202-1 ii libc6 2.37-13 ii libc6-dev 2.37-13 ii libclang-common-17-dev 1:17.0.6-1 ii libclang-cpp17 1:17.0.6-1 ii libclang1-171:17.0.6-1 ii libgcc-13-dev 13.2.0-8 ii libgcc-s1 13.2.0-8 ii libllvm17 1:17.0.6-1 ii libobjc-13-dev 13.2.0-8 ii libstdc++-13-dev13.2.0-8 ii libstdc++6 13.2.0-8 ii llvm-17-linker-tools1:17.0.6-1 Versions of packages clang-17 recommends: ii llvm-17-dev 1:17.0.6-1 ii python3 3.11.6-1 Versions of packages clang-17 suggests: pn clang-17-doc pn wasi-libc -- no debconf information
