clang 15.0.7+ gcc toolchain detection fails when using explicit target triple

[feltech]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

clang fails to find the gcc toolchain when given an explicit (but compatible) --target.

I came across this issue when building the boost library using its b2 build system, who's clang.jam toolset effectively hardcodes to --target=x86_64-pc-linux.

We can simulate this like

$ cat test.cpp 
#include <cstddef>
int main() {}
$ clang++ --target=x86_64-pc-linux -v test.cpp
clang version 17.0.6 (https://github.com/conda-forge/clangdev-feedstock 58d7390157388f8f78fd73851f0ccf1ceb9501ba)
Target: x86_64-pc-linux
Thread model: posix
InstalledDir: /home/dave/.micromamba/envs/clangdev_bug/bin
 "/home/dave/.micromamba/envs/clangdev_bug/bin/clang-17" -cc1 -triple x86_64-pc-linux -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/dave/workspace/AdaptiveCppConan/all -resource-dir /home/dave/.micromamba/envs/clangdev_bug/lib/clang/17 -isysroot /home/dave/.micromamba/envs/clangdev_bug/x86_64-conda-linux-gnu/sysroot -internal-isystem /home/dave/.micromamba/envs/clangdev_bug/lib/clang/17/include -internal-isystem /home/dave/.micromamba/envs/clangdev_bug/x86_64-conda-linux-gnu/sysroot/usr/local/include -internal-externc-isystem /home/dave/.micromamba/envs/clangdev_bug/x86_64-conda-linux-gnu/sysroot/include -internal-externc-isystem /home/dave/.micromamba/envs/clangdev_bug/x86_64-conda-linux-gnu/sysroot/usr/include -fdeprecated-macro -fdebug-compilation-dir=/home/dave/workspace/AdaptiveCppConan/all -ferror-limit 19 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/test-3d8381.o -x c++ test.cpp
clang -cc1 version 17.0.6 based upon LLVM 17.0.6 default target x86_64-conda-linux-gnu
ignoring nonexistent directory "/home/dave/.micromamba/envs/clangdev_bug/x86_64-conda-linux-gnu/sysroot/usr/local/include"
ignoring nonexistent directory "/home/dave/.micromamba/envs/clangdev_bug/x86_64-conda-linux-gnu/sysroot/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/dave/.micromamba/envs/clangdev_bug/lib/clang/17/include
 /home/dave/.micromamba/envs/clangdev_bug/x86_64-conda-linux-gnu/sysroot/usr/include
End of search list.
test.cpp:1:10: fatal error: 'cstddef' file not found
    1 | #include <cstddef>
      |          ^~~~~~~~~
1 error generated.

Checked 15.0.6 (works), 15.0.7, 16.0.6, 17.0.6 (fails).

In #231 a patch was removed that adds conda-specific entries to clang's target triple aliases. The issue also explicitly mentions 15.0.7, so it's surely not a coincidence.

Installed packages

List of packages in environment: "/home/dave/.micromamba/envs/clangdev_bug"

  Name                      Version  Build               Channel    
──────────────────────────────────────────────────────────────────────
  _libgcc_mutex             0.1      conda_forge         conda-forge
  _openmp_mutex             4.5      2_gnu               conda-forge
  binutils_impl_linux-64    2.40     hf600244_0          conda-forge
  binutils_linux-64         2.40     hbdbef99_2          conda-forge
  clang                     17.0.6   hda56bd4_2          conda-forge
  clang-17                  17.0.6   default_hb11cfb5_2  conda-forge
  clang-format              17.0.6   default_hb11cfb5_2  conda-forge
  clang-format-15           15.0.6   default_h2e3cab8_0  conda-forge
  clang-format-17           17.0.6   default_hb11cfb5_2  conda-forge
  clang-tools               17.0.6   default_hb11cfb5_2  conda-forge
  clangdev                  17.0.6   default_hb11cfb5_2  conda-forge
  clangxx                   17.0.6   default_hb11cfb5_2  conda-forge
  gcc_impl_linux-64         13.2.0   h338b0a0_5          conda-forge
  gcc_linux-64              13.2.0   h112eaf3_2          conda-forge
  gxx_impl_linux-64         13.2.0   h338b0a0_5          conda-forge
  gxx_linux-64              13.2.0   hc53e3bf_2          conda-forge
  icu                       73.2     h59595ed_0          conda-forge
  kernel-headers_linux-64   2.6.32   he073ed8_17         conda-forge
  ld_impl_linux-64          2.40     h41732ed_0          conda-forge
  libclang                  17.0.6   default_hb11cfb5_2  conda-forge
  libclang-cpp              17.0.6   default_hb11cfb5_2  conda-forge
  libclang-cpp15            15.0.6   default_h2e3cab8_0  conda-forge
  libclang-cpp17            17.0.6   default_hb11cfb5_2  conda-forge
  libclang13                17.0.6   default_ha2b6cf4_2  conda-forge
  libgcc-devel_linux-64     13.2.0   ha9c7c90_105        conda-forge
  libgcc-ng                 13.2.0   h807b86a_5          conda-forge
  libgomp                   13.2.0   h807b86a_5          conda-forge
  libiconv                  1.17     hd590300_2          conda-forge
  libllvm15                 15.0.6   h63197d8_0          conda-forge
  libllvm17                 17.0.6   hb3ce162_1          conda-forge
  libsanitizer              13.2.0   h7e041cc_5          conda-forge
  libstdcxx-devel_linux-64  13.2.0   ha9c7c90_105        conda-forge
  libstdcxx-ng              13.2.0   h7e041cc_5          conda-forge
  libxml2                   2.12.5   h232c23b_0          conda-forge
  libzlib                   1.2.13   hd590300_5          conda-forge
  llvm-tools                17.0.6   hb3ce162_1          conda-forge
  llvmdev                   17.0.6   hb3ce162_1          conda-forge
  sysroot_linux-64          2.12     he073ed8_17         conda-forge
  xz                        5.2.6    h166bdaf_0          conda-forge
  zstd                      1.5.5    hfc55251_0          conda-forge

Environment info

libmamba version : 1.5.6
     micromamba version : 1.5.6
           curl version : libcurl/8.5.0 OpenSSL/3.2.0 zlib/1.2.13 zstd/1.5.5 libssh2/1.11.0 nghttp2/1.58.0
     libarchive version : libarchive 3.7.2 zlib/1.2.13 bz2lib/1.0.8 libzstd/1.5.5
       envs directories : /home/dave/.micromamba/envs
          package cache : /home/dave/.micromamba/pkgs
                          /home/dave/.mamba/pkgs
            environment : clangdev_bug (active)
           env location : /home/dave/.micromamba/envs/clangdev_bug
      user config files : /home/dave/.mambarc
 populated config files : /home/dave/.condarc
                          /home/dave/.conda/.condarc
       virtual packages : __unix=0=0
                          __linux=5.4.0=0
                          __glibc=2.31=0
                          __archspec=1=x86_64-v3
                          __cuda=12.3=0
               channels : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
       base environment : /home/dave/.micromamba
               platform : linux-64

[h-vetinari]

In #231 a patch was removed that adds conda-specific entries to clang's target triple aliases.

We don't really have support for clang on linux. That said, #227 (which #231 fixed) was about a very similar problem - not finding the C++ stdlib on linux, so it's interesting that the fix for that ends up breaking your usage of it.

I'm not sure where you got your flag setup from, but basically, you need to extend your include path to also contain the location where libstdcxx-devel_linux-64 lives (which is already in your env), i.e.: $PREFIX/x86_64-conda-linux-gnu/include

The more comprehensive fix for all this (modulo conda-forge/clang-compiler-activation-feedstock#118) will arrive hopefully soon through conda-forge/ctng-compiler-activation-feedstock#100 resp. conda-forge/ctng-compiler-activation-feedstock#101

[isuruf]

@feltech, I didn't think anyone would send a triple that way. We can restore that patch. I'm pretty sure, the PRs mentioned by @h-vetinari will not fix this issue.

[h-vetinari]

I'm pretty sure, the PRs mentioned by @h-vetinari will not fix this issue.

My assumption was that with the right compiler activation, we can handle it. If not, then we'll have to find another way.

It sounds like you already know how the handling for arbitrary triples should look like...

[h-vetinari]

@feltech, I didn't think anyone would send a triple that way. We can restore that patch

I've opened PRs for 15.x, 16.x, 17.x & main that reinstate the respective patch.

[feltech]

I've opened PRs for 15.x, 16.x, 17.x & main that reinstate the respective patch.

Thanks! I did just give #102 (replacement for #101 that you posted) a go, which, if I'm understanding correctly, added clang_linux-64. I made a new environment, installed clangxx_linux-64 and ran the --target test in my original post. But unfortunately saw the same problem.

I still haven't wrapped my head around the structure of these feedstocks, but if there are automated tests, perhaps the little test I posted could be incorporated as a regression test?

[h-vetinari]

Thanks! I did just give #102 (replacement for #101 that you posted) a go, which, if I'm understanding correctly, added clang_linux-64.

I presume you're referring to conda-forge/ctng-compiler-activation-feedstock#102, not #102? In any case, as Isuru said, the clang compiler activation doesn't concern the detection of our somewhat custom location for libstdcxx. You'll be able to test it as soon as the PR #277 (or newer) is merged.

[feltech]

Thanks! I did just give #102 (replacement for #101 that you posted) a go, which, if I'm understanding correctly, added clang_linux-64.

I presume you're referring to conda-forge/ctng-compiler-activation-feedstock#102

Yes indeed, whoops 🙄

the clang compiler activation doesn't concern the detection of our somewhat custom location for libstdcxx

Yeah I figured as much, but thought it worth a shot.

You'll be able to test it as soon as the PR #277 (or newer) is merged.

Looking forward to it, thanks.

[h-vetinari]

OK, those PRs were merged, in a couple hours you should have the new builds for 15.x-18.x available. Please let us know if you still run into issues after that. In the meantime, I'm closing this as resolved.

[feltech]

I tried 17.0.6 with the test above, and it works! Thanks again!