Bugzilla – Bug 1216121
rust1.7{1,2,3} fail to build with newest binutils
Last modified: 2024-06-20 12:39:46 UTC
I have no idea why rust1.7{1,2,3} fails, I just note that with the new binutils https://build.opensuse.org/request/show/1113885 as shown below. The current error message does not point to anything obvious with regards to binutils - but looks more like a generic Rust build issue. But it as it does compile on opensuse:Factory, it must have something to do with binutils. The fails is: [ 191s] Finished release [optimized] target(s) in 1m 54s [ 192s] Building LLD for x86_64-unknown-linux-gnu ... [ 192s] CMake Deprecation Warning at /home/abuild/rpmbuild/BUILD/rustc-1.73.0-src/src/llvm-project/cmake/Modules/CMakePolicy.cmake:6 (cmake_policy): [ 192s] The OLD behavior for policy CMP0114 will be removed from a future version [ 192s] of CMake. [ 192s] [ 192s] The cmake-policies(7) manual explains that the OLD behaviors of all [ 192s] policies are deprecated and that a policy should be set to OLD only under [ 192s] specific short-term circumstances. Projects should be ported to the NEW [ 192s] behavior and not rely on setting a policy to OLD. [ 192s] Call Stack (most recent call first): [ 192s] CMakeLists.txt:6 (include) [ 192s] [ 192s] [ 192s] -- The C compiler identification is GNU 13.2.1 [ 192s] -- The CXX compiler identification is GNU 13.2.1 [ 192s] -- Detecting C compiler ABI info [ 192s] -- Detecting C compiler ABI info - done ... [ 194s] -- Configuring done (2.2s) [ 194s] CMake Error at /usr/lib64/cmake/llvm/AddLLVM.cmake:714 (target_link_libraries): [ 194s] Target "lldELF" links to: [ 194s] [ 194s] zstd::libzstd_static [ 194s] [ 194s] but the target was not found. Possible reasons include: [ 194s] [ 194s] * There is a typo in the target name. [ 194s] * A find_package call is missing for an IMPORTED target. [ 194s] * An ALIAS target is missing. [ 194s] [ 194s] Call Stack (most recent call first): [ 194s] cmake/modules/AddLLD.cmake:13 (llvm_add_library) [ 194s] ELF/CMakeLists.txt:21 (add_lld_library) [ 194s] [ 194s] [ 194s] -- Generating done (0.0s) [ 194s] CMake Warning: [ 194s] Manually-specified variables were not used by the project: [ 194s] [ 194s] CMAKE_ASM_COMPILER [ 194s] [ 194s] [ 194s] CMake Generate step failed. Build files cannot be regenerated correctly. [ 194s] thread 'main' panicked at /home/abuild/rpmbuild/BUILD/rustc-1.73.0-src/vendor/cmake/src/lib.rs:975:5: [ 194s] [ 194s] command did not execute successfully, got: exit status: 1 [ 194s] [ 194s] build script failed, must exit now [ 194s] note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace [ 194s] finished in 2.256 seconds [ 194s] Build completed unsuccessfully in 0:02:30 [ 194s] error: Bad exit status from /var/tmp/rpm-tmp.YhjGx1 (%build)
I don't know why either, but I would assume given this is a binutils problem, shouldn't it be assigned to the binutils maintainer and not me?
I tracked this down as a fun side-effect of the implementation/fix of bug 1215341 In the past, we did not have libzstd-devel in the Buildroot, which made things work 'as they were' Since that bug was fixed (and the fix is part of the current SR of binutils to Factory), we get libzstd-devel in the buldroot. LLVM detects that and wants to use zstd:static in this case... but zstd-devel-static is a different package, not being pulled in. I *think* the correct fix for this would be for llvm*-devel to specifz: Requires: (libzstd-devel-static if libzstd-devel) Or, alternatively, teach llvm to work with zstd shared libs Assigning to llvm maintainer
(In reply to Dominique Leuenberger from comment #2) > In the past, we did not have libzstd-devel in the Buildroot, which made > things work 'as they were' > > Since that bug was fixed (and the fix is part of the current SR of binutils > to Factory), we get libzstd-devel in the buldroot. > > LLVM detects that and wants to use zstd:static in this case... but > zstd-devel-static is a different package, not being pulled in. Right, the build setup detects the library and enables or disables some features based on that. In llvm/CMakeLists.txt: set(LLVM_ENABLE_ZSTD "ON" CACHE STRING "Use zstd for compression/decompression if available. Can be ON, OFF, or FORCE_ON") And llvm/cmake/config-ix.cmake: set(zstd_FOUND 0) if(LLVM_ENABLE_ZSTD) if(LLVM_ENABLE_ZSTD STREQUAL FORCE_ON) # ... elseif(NOT LLVM_USE_SANITIZER MATCHES "Memory.*") find_package(zstd QUIET) endif() endif() set(LLVM_ENABLE_ZSTD ${zstd_FOUND}) So we're using it if available. > I *think* the correct fix for this would be for llvm*-devel to specifz: > > Requires: (libzstd-devel-static if libzstd-devel) If we currently don't have libzstd-devel, we can probably just disable the feature for now, i.e. -DLLVM_ENABLE_ZSTD:BOOL=OFF. > Or, alternatively, teach llvm to work with zstd shared libs That would be better. But I'll defer this to unblock binutils, and maybe only apply it in the latest version. I guess this is used for compressed debug info (compressed in the ELF file itself, not a compressed ELF debug info file), which isn't widely used yet.
(In reply to Tobias Burnus from comment #0) > [ 192s] Building LLD for x86_64-unknown-linux-gnu Side note: why is Rust building their own LLD? We ship a package for that.
(In reply to Aaron Puchert from comment #4) > (In reply to Tobias Burnus from comment #0) > > [ 192s] Building LLD for x86_64-unknown-linux-gnu > > Side note: why is Rust building their own LLD? We ship a package for that. Because the one from llvm keeps breaking in subtle ways. This was the only way to make tests and wasm builds reliable. Even with the patches you previously added, there were just too many ongoing build errors with rust. So we opted to self-contain this to match upstream behaviour.
This is an autogenerated message for OBS integration: This bug (1216121) was mentioned in https://build.opensuse.org/request/show/1119115 Factory / llvm16 https://build.opensuse.org/request/show/1119116 Factory / llvm15
This is an autogenerated message for OBS integration: This bug (1216121) was mentioned in https://build.opensuse.org/request/show/1119122 Factory / llvm17
@Aaron: I see at https://build.opensuse.org/project/show/openSUSE:Factory:Staging:A the fail for several packages: unresolved - "nothing provides clang17-devel = 17.0.2 needed by clang-devel, (got version 17.0.3-1.1)" I see in https://build.opensuse.org/package/view_file/devel:tools:compiler/llvm/llvm.spec?expand=1 Version: 17.0.2 ... %package -n clang-devel ... Requires: clang%{_sonum}-devel = %{version} QUESTION: Do you also need to update 'llvm' and not only 'llvm17'? The latter is https://build.opensuse.org/request/show/1119122
(In reply to Tobias Burnus from comment #8) > Do you also need to update 'llvm' and not only 'llvm17'? The latter > is https://build.opensuse.org/request/show/1119122 Yes, I forget that every now and then. Have been thinking about dropping the minor/patch-level version and just go with the major version, so that I only need to update with the major version every 6 months, not with every patch version.
(In reply to Aaron Puchert from comment #9) > (In reply to Tobias Burnus from comment #8) > > Do you also need to update 'llvm' and not only 'llvm17'? The latter > > is https://build.opensuse.org/request/show/1119122 > > Yes, I forget that every now and then. Just for reference: https://build.opensuse.org/request/show/1119293 has the update.
Fixed for llvm15, llvm16, llvm17. Older versions don't use zstd-devel.
This is an autogenerated message for OBS integration: This bug (1216121) was mentioned in https://build.opensuse.org/request/show/1157115 Backports:SLE-15-SP5 / llvm17