Skip to content

Unable to link RISC-V linux-gnu and linux-musl executables using zig cc and CMake #22165

Description

@fwsGonzo

Zig Version

0.14.0-dev.2384+cbc05e0b1

Steps to Reproduce and Observed Behavior

Simple toolchain file:

set(CMAKE_SYSTEM_NAME "Linux")
set(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_SYSTEM_PROCESSOR "riscv64")
set(CMAKE_CROSSCOMPILING TRUE)
#set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
set(CMAKE_C_COMPILER "zig" cc -target riscv64-linux-gnu)
set(CMAKE_CXX_COMPILER "zig" c++ -target riscv64-linux-gnu)

The try-static-library thing is just to avoid the compiler checks. The linking step fails, so we want the compiler check.

Simple build script:

mkdir -p .zig
pushd .zig
cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE="$TOOLCHAIN"
make -j
popd

Compiler test:

$ bash zig.sh 
~/github/godot-sandbox-programs/.zig ~/github/godot-sandbox-programs
-- The C compiler identification is Clang 19.1.0
-- The CXX compiler identification is Clang 19.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /home/gonzo/zig/zig
-- Check for working C compiler: /home/gonzo/zig/zig - broken
CMake Error at /usr/share/cmake-3.22/Modules/CMakeTestCCompiler.cmake:69 (message):
  The C compiler

    "/home/gonzo/zig/zig"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /home/gonzo/github/godot-sandbox-programs/.zig/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_aaa0d/fast && /usr/bin/gmake  -f CMakeFiles/cmTC_aaa0d.dir/build.make CMakeFiles/cmTC_aaa0d.dir/build
    gmake[1]: Entering directory '/home/gonzo/github/godot-sandbox-programs/.zig/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_aaa0d.dir/testCCompiler.c.o
    /home/gonzo/zig/zig cc -target riscv64-linux-gnu    -MD -MT CMakeFiles/cmTC_aaa0d.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_aaa0d.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_aaa0d.dir/testCCompiler.c.o -c /home/gonzo/github/godot-sandbox-programs/.zig/CMakeFiles/CMakeTmp/testCCompiler.c
    Linking C executable cmTC_aaa0d
    /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_aaa0d.dir/link.txt --verbose=1
    /home/gonzo/zig/zig cc -target riscv64-linux-gnu CMakeFiles/cmTC_aaa0d.dir/testCCompiler.c.o -o cmTC_aaa0d   -latomic 
    error: unable to find dynamic system library 'atomic' using strategy 'paths_first'. searched paths: none
    gmake[1]: *** [CMakeFiles/cmTC_aaa0d.dir/build.make:100: cmTC_aaa0d] Error 1
    gmake[1]: Leaving directory '/home/gonzo/github/godot-sandbox-programs/.zig/CMakeFiles/CMakeTmp'
    gmake: *** [Makefile:127: cmTC_aaa0d/fast] Error 2

It's erroneously trying to link against libatomic: -latomic. Same behavior on both linux-gnu and linux-musl.

As a sanity check I tried to compile manually on the command-line, and that works as -latomic is not being added. But, maybe this is a CMake bug? And is -latomic supposed to be present? Can it be an empty library?

Expected Behavior

Don't link against libatomic.

Activity

  1. added
    bugObserved behavior contradicts documented or intended behavior
    on Dec 6, 2024
  2. fwsGonzo commented on Dec 6, 2024

    @fwsGonzo
    Author

    For those looking for a work-around, if you enable static-library set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY), and then add your own empty library called atomic, it will link just fine.

    CMake bug?

  3. alexrp commented on Dec 6, 2024

    @alexrp
    Member

    You'll have to figure out why CMake is deciding that it needs libatomic. That requirement is definitely not coming from Zig.

  4. fwsGonzo commented on Dec 6, 2024

    @fwsGonzo
    Author

    Alright, well all's well that ends well anyway. All my programs are linking, so there is definitely no actual need for -latomic.

    if (ZIG_COMPILER)
    	add_library(atomic STATIC "${CMAKE_SOURCE_DIR}/ext/atomic.c")
    endif()

    I added an empty atomic.c file to a folder, and created a library from it. That was enough to make everything work.

  5. alexrp commented on Dec 6, 2024

    @alexrp
    Member

    Reopening this actually. I think that, regardless of whatever CMake is doing here, it makes sense for us to recognize and treat libatomic specially as it's a compiler-provided library. Our compiler-rt implementation should be able to satisfy it (as evidenced by your workaround actually working).

  6. reopened this on Dec 6, 2024
  7. added
    enhancementSolving this issue will likely involve adding new logic or components to the codebase.
    and removed
    bugObserved behavior contradicts documented or intended behavior
    on Dec 6, 2024
  8. added this to the 0.14.0 milestone on Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementSolving this issue will likely involve adding new logic or components to the codebase.linking

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions