Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CMake] Debian "Could NOT find ZLIB" when using a -DLLVM_ENABLE_RUNTIMES build of clang #57259

Open
MaskRay opened this issue Aug 20, 2022 · 5 comments
Labels
build-problem cmake Build system in general and CMake in particular

Comments

@MaskRay
Copy link
Member

MaskRay commented Aug 20, 2022

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 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.

https://gist.github.com/glandium/6c130dee608f9585b425c4a40a084d27

% cat Dockerfile
FROM debian:testing-20220801
RUN echo deb http://snapshot.debian.org/archive/debian/20220801T205040Z/ testing main > /etc/apt/sources.list ;\
    apt-get -o Acquire::Check-Valid-Until=false update; \
    apt-get install -y build-essential git cmake ninja-build libc6-dev-i386 python3; \
    git clone https://github.com/llvm/llvm-project; \
    cd llvm-project; \
    git checkout 311f7839602344ca347816146edb68c0ffaaa060; \
    cmake llvm -B obj -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/tmp/llvm/stage1 -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi"; \
    ninja -C obj install; \
    cmake llvm -B obj2 -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang" -DCMAKE_C_COMPILER=/tmp/llvm/stage1/bin/clang -DCMAKE_CXX_COMPILER=/tmp/llvm/stage1/bin/clang++ 2>&1 | grep ZLIB
RUN cd llvm-project; ninja -C obj2 llvm-mc && readelf -d obj2/bin/llvm-mc
% podman build .
...
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)                                                                               
-- Could NOT find LibXml2 (missing: LIBXML2_LIBRARY LIBXML2_INCLUDE_DIR)                                                                      
-- Could NOT find LibEdit (missing: LibEdit_INCLUDE_DIRS LibEdit_LIBRARIES)                                                                   
-- Could NOT find Terminfo (missing: Terminfo_LIBRARIES Terminfo_LINKABLE)
...
[1711/1711] Linking CXX executable bin/llvm-mc

Dynamic section at offset 0x200ac08 contains 35 entries:
  Tag        Type                         Name/Value     ############ no libz.so.1 or libtinfo.so.6
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib]

@glandium's comment is related

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.

@MaskRay MaskRay added cmake Build system in general and CMake in particular build-problem labels Aug 20, 2022
@mstorsjo
Copy link
Member

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.)

@glandium
Copy link
Contributor

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".

@glandium
Copy link
Contributor

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.

@dwblaikie
Copy link
Collaborator

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...

@glandium
Copy link
Contributor

glandium commented Aug 26, 2022

A similar problem with libpthread was worked around in 8537a99

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build-problem cmake Build system in general and CMake in particular
Projects
None yet
Development

No branches or pull requests

4 participants