Unable to build static binary

Project Infrastructure LLVM Dev List Archives
1

I’m currently having issues trying to rebuild one of my projects with an updated version of LLVM. This project generates a statically linked binary.

My previous build used llvm-10.0.0 and I could build the binary without any issues. When I checked out HEAD a few weeks ago (commit 82fbc5d) and tried a build, it failed with the following linking error:

/usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 -O3 -DNDEBUG -static -Wl,-rpath-link,/home/danie/nett-testing/tmp/llvm-project/build/./lib -Wl,-O3 -Wl,–gc-sections -o -Wl,-rpath,“$ORIGIN/…/lib” lib/libLLVMSupport.a -lpthread -static-libgcc -static-libstdc++ lib/libclangTooling.a lib/libclangBasic.a lib/libclangASTMatchers.a lib/libclangFormat.a lib/libclangToolingInclusions.a lib/libclangFrontend.a lib/libclangDriver.a lib/libclangParse.a lib/libclangSerialization.a lib/libclangSema.a lib/libclangEdit.a lib/libclangAnalysis.a lib/libclangASTMatchers.a lib/libclangAST.a lib/libclangToolingCore.a lib/libclangRewrite.a lib/libclangLex.a lib/libclangBasic.a lib/libLLVMOption.a lib/libLLVMFrontendOpenMP.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis.a lib/libLLVMProfileData.a lib/libLLVMObject.a lib/libLLVMBitReader.a lib/libLLVMCore.a lib/libLLVMRemarks.a lib/libLLVMBitstreamReader.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMTextAPI.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a -lrt -ldl -lpthread -lm /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libtinfo.so lib/libLLVMDemangle.a && :
/usr/bin/ld: attempted static link of dynamic object `/usr/lib/x86_64-linux-gnu/libz.so’

I haven’t changed my CMakeLists.txt file, and I’m lost as to how to fix this issue. Any help would be appreciated. For reference, my CMakeLists.txt file as as follows:

— BEGIN CMakeLists.txt —
set(LLVM_LINK_COMPONENTS support)

add_clang_executable(mybinary

)

set (GCC_COMPILE_FLAGS “-O3”)
set (GCC_LINK_FLAGS “-static”)
set (CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} ${GCC_COMPILER_FLAGS}”)
set (CMAKE_EXE_LINKER_FLAGS “${CMAKE_EXE_LINKER_FLAGS} ${GCC_LINK_FLAGS}”)

target_link_libraries(mybinary
PRIVATE
-static-libgcc
-static-libstdc++
clangTooling
clangBasic
clangASTMatchers
)
— END CMakeLists.txt —

Kind regards and thank you in advance,
Danie Grobbelaar

2

This can be an issue of the CMake module called by find_package(ZLIB)

As a workaround, -DLLVM_ENABLE_ZLIB=off, but some zlib features will be
disabled (clang -gz, ld.lld's ability to read/write compressed debug sections).

3

Thank you for that.
Using it, I managed to get the static versions of zlib and libtinfo with the following:
set(CMAKE_FIND_LIBRARY_SUFFIXES “.a”)

find_package(ZLIB REQUIRED)

find_library(TINFO “libtinfo” REQUIRED)

target_link_libraries(prog
PRIVATE
clangTooling clangBasic clangASTMatchers
-static-libgcc -static-libstdc++ -static
${ZLIB} ${TINFO}
)

However I now have the issue where I can’t seem to remove the link to the dynamic versions of the libraries. Note the following output:

/usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 -O3 -DNDEBUG -Wl,-rpath-link,/home/danie/nett-testing/tmp/llvm-project/build/./lib -Wl,-O3 -Wl,–gc-sections -o -Wl,-rpath,“$ORIGIN/…/lib” lib/libLLVMSupport.a -lpthread lib/libclangTooling.a lib/libclangBasic.a lib/libclangASTMatchers.a -static-libgcc -static-libstdc++ -static /usr/lib/x86_64-linux-gnu/libz.a /usr/lib/x86_64-linux-gnu/libtinfo.a lib/libclangFormat.a lib/libclangToolingInclusions.a lib/libclangFrontend.a lib/libclangDriver.a lib/libclangParse.a lib/libclangSerialization.a lib/libclangSema.a lib/libclangEdit.a lib/libclangAnalysis.a lib/libclangASTMatchers.a lib/libclangAST.a lib/libclangToolingCore.a lib/libclangRewrite.a lib/libclangLex.a lib/libclangBasic.a lib/libLLVMOption.a lib/libLLVMFrontendOpenMP.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis.a lib/libLLVMProfileData.a lib/libLLVMObject.a lib/libLLVMBitReader.a lib/libLLVMCore.a lib/libLLVMRemarks.a lib/libLLVMBitstreamReader.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMTextAPI.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a -lrt -ldl -lpthread -lm /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libtinfo.so lib/libLLVMDemangle.a && :
/usr/bin/ld: attempted static link of dynamic object `/usr/lib/x86_64-linux-gnu/libz.so’

Is there a way to let cmake know which libraries I want?

Kind regards and thank you in advance,
Danie Grobbelaar

4

Here my notes are:
-Others were getting somewhere else such errors too and were equally puzzled
-I wonder if llvm.lld could be even nicer in saying something like:
“When trying to statically link with options , dynamic object was found on a chain due to options <either explicit so mention or offending -llibname etc>, please consider switching to dynamic link with or using static version of ”
-If above is too much, entry in documentation and url to article could be good enough as second line of error message.

Pawel

sob., 8.05.2021, 04:50 użytkownik Danie Grobbelaar via llvm-dev <llvm-dev@lists.llvm.org> napisał:

5

On the one after patched cmake script i would wonder if You could try to bisect-find command line option(s) causing libz.so and libtinfo.so getting included anyway. It could be maybe -lpthreads or some other -l having libz.so in its dependencies. If you try this youll likely get unresolved symbols but dont worry from -lpthread or some other -l but libz.so and libtinfo.so references includer(s) would get found in this way. Then i would try to replace these ones referencing libz.so and libtinfo.so with ones that reference static versions of those. Hope this helps a little.

Pawel

wt., 11.05.2021, 07:05 użytkownik Danie Grobbelaar via llvm-dev <llvm-dev@lists.llvm.org> napisał: