You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Debian, if one uses a -DLLVM_ENABLE_RUNTIMES='compiler-rt;libcxx;libcxxabi' build of clang as CMAKE_C_COMPILER and CMAKE_CXX_COMPILER, some system libraries like /usr/lib/x86_64-linux-gnu/libz.so cannot be found in some circumstances.`
It is related to the new runtime hierarchy (e.g. lib/clang/15.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a) and Debian's multiarch scheme (no vendor part in x86_64-linux-gnu). In early days Debian made a decision to omit "vendor" in the target triple in GCC and its filesystem hierarchy. Clang Driver has quite involved logic to support Debian style multiarch.
I don't know how this works for you. CMake gets a list of implicit link dirs from parsing the ld command that clang -v outputs when linking. When $clang/lib/x86_64-unknown-linux-gnu exists, that's part of that output. Then, CMake determines the arch it later uses when finding libraries by matching architectures in each of the implicit link dirs, and $clang/lib/x86_64-unknown-linux-gnu is the first match. From there it uses x86_64-unknown-linux-gnu, and of course it doesn't find libraries in /usr/lib/x86_64-linux-gnu because it never looks there in find_library. That can even affect pkg-config, because it uses that same derived architecture to find pkgconfig directories. When $clang/lib/x86_64-unknown-linux-gnu doesn't exist, /lib/x86_64-linux-gnu is the first match, and it uses x86_64-linux-gnu as arch, and that works.
I am unable to reproduce the issue with my Debian testing machine with many more files than the Dockerfile build.
Here is a local build with -DCMAKE_INSTALL_PREFIX=/tmp/install/custom1 -DLLVM_ENABLE_PROJECTS=clang -DLLVM_ENABLE_RUNTIMES='compiler-rt;libcxx;libcxxabi;libunwind'.
[3723/3735] Performing configure step for 'builtins'...-- Could NOT find Terminfo (missing: Terminfo_LIBRARIES Terminfo_LINKABLE) -- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11") -- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.14")..[3724/3735] Performing build step for 'builtins' [306/306] Linking C static library /tmp/out/custom1/lib/clang/16.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a [3725/3735] No install step for 'builtins' [3732/3735] Performing configure step for 'runtimes'...-- Found Terminfo: /usr/lib/x86_64-linux-gnu/libtinfo.so -- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11") -- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.14")
If I use the built clang to configure a stage-2 build: -DCMAKE_INSTALL_PREFIX=/tmp/install/s2-custom1 -DLLVM_ENABLE_PROJECTS=llvm -DCMAKE_C_COMPILER=/tmp/install/custom1/bin/clang -DCMAKE_CXX_COMPILER=/tmp/install/custom1/bin/clang++
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11") -- Looking for compress2-- Looking for compress2 - found-- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.14") -- Looking for xmlReadMemory-- Looking for xmlReadMemory - found-- Could NOT find LibEdit (missing: LibEdit_INCLUDE_DIRS LibEdit_LIBRARIES) -- Performing Test Terminfo_LINKABLE -- Performing Test Terminfo_LINKABLE - Success-- Found Terminfo: /usr/lib/x86_64-linux-gnu/libtinfo.so
zlib is found.
The text was updated successfully, but these errors were encountered:
I am unable to reproduce the issue with my Debian testing machine with many more files than the Dockerfile build.
The point of the Dockerfile is that it is exactly reproducible - so instead of trying to do similar-ish commands in a similar-ish environment, you can reproduce exactly what he experienced. I downloaded that Dockerfile, placed it an empty directory and ran docker build ., and got the issue reproduced.
(I'm not involved in the matter other than that, but I'd like to see it resolved, whatever the issue is.)
Note that it's not only about Debian omitting the vendor part of the target triple. The same problem would happen with e.g. "x86_64-pc-linux-gnu" vs. "x86_64-unknown-linux-gnu" (a typical variation) or "i386-pc-linux-gnu" vs. "i686-pc-linux-gnu".
Arguably, this could be considered as a cmake bug, since it all comes from how it derives the system multiarch directory from whatever comes first in the library lookup path, which now includes a clang path that contains something that looks like a multiarch directory.
oh, that's good to know this is identified - explains why I've been using -DZLIB_LIBRARY=/usr/lib/x86_64-linux-gnu/libz.so in my cmake config for a while/recently...
Originally reported by @glandium on https://reviews.llvm.org/D107799#3565520 . I moved it here since the issue isn't so related to that config toggle patch.
On Debian, if one uses a
-DLLVM_ENABLE_RUNTIMES='compiler-rt;libcxx;libcxxabi'
build of clang asCMAKE_C_COMPILER
andCMAKE_CXX_COMPILER
, some system libraries like/usr/lib/x86_64-linux-gnu/libz.so
cannot be found in some circumstances.`It is related to the new runtime hierarchy (e.g.
lib/clang/15.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a
) and Debian's multiarch scheme (no vendor part inx86_64-linux-gnu
). In early days Debian made a decision to omit "vendor" in the target triple in GCC and its filesystem hierarchy. Clang Driver has quite involved logic to support Debian style multiarch.https://gist.github.com/glandium/6c130dee608f9585b425c4a40a084d27
@glandium's comment is related
I am unable to reproduce the issue with my Debian testing machine with many more files than the
Dockerfile
build.Here is a local build with
-DCMAKE_INSTALL_PREFIX=/tmp/install/custom1 -DLLVM_ENABLE_PROJECTS=clang -DLLVM_ENABLE_RUNTIMES='compiler-rt;libcxx;libcxxabi;libunwind'
.If I use the built clang to configure a stage-2 build:
-DCMAKE_INSTALL_PREFIX=/tmp/install/s2-custom1 -DLLVM_ENABLE_PROJECTS=llvm -DCMAKE_C_COMPILER=/tmp/install/custom1/bin/clang -DCMAKE_CXX_COMPILER=/tmp/install/custom1/bin/clang++
zlib is found.
The text was updated successfully, but these errors were encountered: