clang does not pass the sysroot to the linker on Linux

[ImpleLee]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

clang does not pass the sysroot to the linker, making lld unable to find libc.so.6.

Example

Create a file named a.c with the following content.

#include <stdio.h>

int main() {
  puts("Hello, world!");
  return 0;
}

Then run the following line in bash.

$ clang a.c -fuse-ld=lld
ld.lld: error: cannot open /lib64/libc.so.6: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This is because lld does not know sysroot, so it cannot find the correct lib64/libc.so.6 (at x86_64-conda-linux-gnu/sysroot/lib64/libc.so.6). bfd and gold can both run the program however.

Supply the sysroot when calling clang resolves the problem.

$ clang a.c -fuse-ld=lld --sysroot=$CONDA_PREFIX/x86_64-conda-linux-gnu/sysroot
$ ./a.out
Hello, world!

Installed packages

# 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
ca-certificates           2023.7.22            hbcca054_0    conda-forge
clang                     17.0.2               ha0738ec_0    conda-forge
clang-17                  17.0.2          default_h1cdf331_0    conda-forge
clangxx                   17.0.2          default_h1cdf331_0    conda-forge
gcc                       13.2.0               h574f8da_2    conda-forge
gcc_impl_linux-64         13.2.0               h338b0a0_2    conda-forge
gxx                       13.2.0               h574f8da_2    conda-forge
gxx_impl_linux-64         13.2.0               h338b0a0_2    conda-forge
icu                       73.2                 h59595ed_0    conda-forge
kernel-headers_linux-64   2.6.32              he073ed8_16    conda-forge
ld_impl_linux-64          2.40                 h41732ed_0    conda-forge
libclang-cpp17            17.0.2          default_h1cdf331_0    conda-forge
libgcc-devel_linux-64     13.2.0               ha9c7c90_2    conda-forge
libgcc-ng                 13.2.0               h807b86a_2    conda-forge
libgomp                   13.2.0               h807b86a_2    conda-forge
libhwloc                  2.9.3           default_h554bfaf_1009    conda-forge
libiconv                  1.17                 h166bdaf_0    conda-forge
libllvm17                 17.0.2               h5cf9203_0    conda-forge
libsanitizer              13.2.0               h7e041cc_2    conda-forge
libstdcxx-devel_linux-64  13.2.0               ha9c7c90_2    conda-forge
libstdcxx-ng              13.2.0               h7e041cc_2    conda-forge
libxml2                   2.11.5               h232c23b_1    conda-forge
libzlib                   1.2.13               hd590300_5    conda-forge
lld                       17.0.2               hcfcaf08_0    conda-forge
mimalloc                  2.1.2                h59595ed_1    conda-forge
mold                      2.2.0                h76aa41c_0    conda-forge
openssl                   3.1.3                hd590300_0    conda-forge
sysroot_linux-64          2.12                he073ed8_16    conda-forge
tbb                       2021.10.0            h00ab1b0_1    conda-forge
xz                        5.4.2                h5eee18b_0    defaults
zstd                      1.5.5                hfc55251_0    conda-forge

Environment info

            shell level : 2
       user config file : $HOME/.condarc
 populated config files : $HOME/.condarc
          conda version : 23.9.0
    conda-build version : not installed
         python version : 3.10.13.final.0
       virtual packages : __archspec=1=x86_64
                          __cuda=12.0=0
                          __glibc=2.31=0
                          __linux=5.11.0=0
                          __unix=0=0
       base environment : $HOME/miniconda3  (writable)
      conda av data dir : $HOME/miniconda3/etc/conda
  conda av metadata url : None
          package cache : $HOME/miniconda3/pkgs
                          $HOME/.conda/pkgs
       envs directories : $HOME/miniconda3/envs
                          $HOME/.conda/envs
               platform : linux-64
             user-agent : conda/23.9.0 requests/2.31.0 CPython/3.10.13 Linux/5.11.0-27-generic ubuntu/20.04.3 glibc/2.31
             netrc file : None
           offline mode : False

[h-vetinari]

We have a separate feedstock that handles the compiler activation for clang, which generally sets all the things so that the resulting compiler is usable. These are installable through clang_{{ target_platform }} and clangxx_{{ target_platform }}.

HOWEVER, we don't have such a thing for clang on linux, because - wherever possible - we try to use only one compiler stack per platform, and providing clang_linux-64 would enable feedstocks to use it as "the" C/CXX-compiler, which can lead to ABI problems vs. GCC (and which standard library resp. runtime is used, etc. etc.).

I would not be against doing a "mini-activation" for the linux builds of clang on this feedstock, IOW, ensuring that --sysroot and some other basics are there if someone installs the clang output on linux. At least it would make our clang builds here more useful for endusers on linux (without opening it up for use in the general compiler infrastructure).

Not sure what the rest of @conda-forge/clangdev thinks though.

[igozali]

is this possibly related to #249?

[xhochy]

A clang activation for Linux would be useful as I would also like to use it sometimes for building things. It should be in the activation feedstock.

[h-vetinari]

It should be in the activation feedstock.

Do I understand you correctly that you're proposing to introduce clang_linux-64?

[xhochy]

Yes, but don't expect it to happen anytime soon.

[isuruf]

I tried that recently and realized that some of the symlinks are in wrong packages. See my WIP PR conda-forge/ctng-compilers-feedstock#112

[isuruf]

and providing clang_linux-64 would enable feedstocks to use it as "the" C/CXX-compiler, which can lead to ABI problems vs. GCC (and which standard library resp. runtime is used, etc. etc.).

This is not true. clang will use the same standard library (libstdc++) on Linux.

[h-vetinari]

I said "can lead to", so that statement is true on the face of it, because -stdlib=libc++ could be set by a feedstock.

In any case, I was just describing my understanding about why we don't have a separate compiler stack on linux. If we can allow ourselves to be less restrictive on this, all the better!

[h-vetinari]

The sysroot part of this discussion (i.e. what's in the OP) is solved by #251 / #252

[h-vetinari]

I opened an issue for supporting clang as a compiler on linux: conda-forge/clang-compiler-activation-feedstock#117