ldc icon indicating copy to clipboard operation
ldc copied to clipboard

CMake error on macOS Monterey, library not found for -lpthread

Open JohanEngelen opened this issue 4 years ago • 7 comments

The first time running cmake on macOS Monterey, I see this error:

CMake Error at cmake/Modules/ExtractDMDSystemLinker.cmake:42 (message):
  Failed to link empty D program using
  '/Users/johan/dcompilers/ldc-1.27.1-johan/bin/ldmd2 -wi -link-debuglib':

  ld: library not found for -lpthread

  clang: error: linker command failed with exit code 1 (use -v to see
  invocation)

  Error: /Library/Developer/CommandLineTools/usr/bin/cc failed with status: 1
Call Stack (most recent call first):
  CMakeLists.txt:670 (include)

Simply rerunning cmake works and creates a fine build configuration for LDC (ninja works fine afterwards).

I've traced the problem down to the following: There are two cc executables on macOS: /usr/bin/cc and /Library/Developer/CommandLineTools/usr/bin/cc. The first one, /usr/bin/cc is usually used by LDC, and correctly finds libpthread, so LDC can link executables without problem. The second one, /Library/Developer/CommandLineTools/usr/bin/cc, is not able to find libpthread and therefore fails linking when invoked by LDC. In the execute_process enviroment of CMake, the CC environment variable is set to /Library/Developer/CommandLineTools/usr/bin/cc; this is the C compiler detected by CMake (CMake outputs: -- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped). LDC uses the CC variable to find the C compiler, thus the linking problem occurs. I wonder if this is a problem in CMake, that should detect /usr/bin/cc instead of the other one. I'm using CMake 3.22.1.

JohanEngelen avatar Jan 16 '22 21:01 JohanEngelen

Thanks, finally some insights for https://github.com/ldc-developers/ldc/pull/3871. [It's apparently /Applications/Xcode_12.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc for that GH Actions image.]

kinke avatar Jan 16 '22 21:01 kinke

I wonder if we can "fix" this by setting CC temporarily to nothing for execute_process...

JohanEngelen avatar Jan 17 '22 22:01 JohanEngelen

Solutions that work:

  • cmake -G Ninja -DCMAKE_C_COMPILER=/usr/bin/cc ......
  • cmake -G Ninja -DD_COMPILER_FLAGS=-gcc=/usr/bin/cc .......

These do not work:

  • CC=/usr/bin/cc cmake -G Ninja ......
  • export CC=/usr/bin/cc cmake .......

JohanEngelen avatar Jan 18 '22 21:01 JohanEngelen

Yeah, I've seen/wondered about CC apparently being ignored by CMake here; for Linux jobs, we used to set CC and CXX IIRC, and that worked fine. The -DD_COMPILER_FLAGS=-gcc=/usr/bin/cc didn't work in #3903 either. [There's also https://github.com/ldc-developers/ldc/blob/41de641a2cdc67ce8b10b0cf7904f7c9069c9b06/cmake/Modules/BuildDExecutable.cmake#L98, but only used for LDC_LINK_MANUALLY=OFF.]

kinke avatar Jan 18 '22 21:01 kinke

There's also https://github.com/ldc-developers/ldc/blob/41de641a2cdc67ce8b10b0cf7904f7c9069c9b06/cmake/Modules/BuildDExecutable.cmake#L98 but only used for LDC_LINK_MANUALLY=OFF.

That turned out to be the problem for CI (using LDC_LINK_MANUALLY=OFF) - -gcc was overwritten (to something like /Applications/Xcode_13.2.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++). https://github.com/ldc-developers/ldc/pull/3951/commits/b646b4c1dfed5b16af1dc38996afa25334661ffc prevents the overwriting, so that -DLDC_LINK_MANUALLY=OFF -DD_COMPILER_FLAGS="-gcc=/usr/bin/c++" works.

kinke avatar Mar 31 '22 22:03 kinke

So should we stop adding -lpthread -lm as default platform libs for Darwin? I guess these symlinks (to -lSystem according to https://github.com/ldc-developers/ldc/pull/3871#discussion_r757755548) somehow aren't available for some /Library/Developer/CommandLineTools/usr/bin/cc anymore, but libSystem would be.

kinke avatar Feb 24 '23 01:02 kinke