BUG: Build with LLVM_BUILD_LLVM_C_DYLIB=ON fails on osx

[h-vetinari]

Based on

llvm-project/llvm/tools/llvm-shlib/CMakeLists.txt

Lines 82 to 85 in 1c822e1

	if(LLVM_BUILD_LLVM_C_DYLIB AND NOT MSVC)
	if(NOT APPLE)
	message(FATAL_ERROR "Generating libLLVM-c is only supported on Darwin")
	endif()

it looks like LLVM_BUILD_LLVM_C_DYLIB=ON should definitely be supported on osx, however, actually setting it results in a build failure (which might be a build ordering issue, because it cannot find libLLVM.dylib, which definitely gets built).

The stack trace below is from 17.0.0.rc2, but it has been the same for the 16.x series, and I presume it's the same for main. Xref also #43487.

[...]
[3369/3461] Linking CXX executable bin/llvm-rust-demangle-fuzzer
[3370/3461] Generating Export list for LLVM...
error: nm: can't open file: $SRC_DIR/build/./lib/libLLVM.dylib (No such file or directory)
[3371/3461] Creating export file for LLVM-C
[3372/3461] Building CXX object tools/llvm-shlib/CMakeFiles/LLVM-C.dir/libllvm.cpp.o
[3373/3461] Linking CXX shared library lib/libLLVM-C.17.dylib
FAILED: lib/libLLVM-C.17.dylib 
: && $BUILD_PREFIX/bin/x86_64-apple-darwin13.4.0-clang++ -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -fmessage-length=0 -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/llvm-package-17.0.0.rc2 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -O3 -DNDEBUG -isysroot /Applications/Xcode_13.2.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.9 -dynamiclib -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs -Wl,-rpath,$PREFIX/lib -L$PREFIX/lib   -Wl,-dead_strip -Wl,-exported_symbols_list,"$SRC_DIR/build/tools/llvm-shlib/LLVM-C.exports" -compatibility_version 1 -current_version 17.0.0 -Wl,-reexport_library $SRC_DIR/build/./lib/libLLVM.dylib  -compatibility_version 17.0.0 -current_version 17.0.0 -o lib/libLLVM-C.17.dylib -install_name @rpath/libLLVM-C.17.dylib tools/llvm-shlib/CMakeFiles/LLVM-C.dir/libllvm.cpp.o  -Wl,-rpath,@loader_path/../lib  lib/libLLVM-17.dylib && :
clang-15: error: no such file or directory: '$SRC_DIR/build/./lib/libLLVM.dylib'
[3374/3461] Building CXX object tools/llvm-sim/CMakeFiles/llvm-sim.dir/llvm-sim.cpp.o
ninja: build stopped: subcommand failed.

CMake invocation

cmake -GNinja \
      -DCMAKE_INSTALL_PREFIX="${PREFIX}" \
      -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_LIBRARY_PATH="${PREFIX}" \
      -DLLVM_ENABLE_BACKTRACES=ON \
      -DLLVM_ENABLE_DUMP=ON \
      -DLLVM_ENABLE_LIBEDIT=OFF \
      -DLLVM_ENABLE_LIBXML2=FORCE_ON \
      -DLLVM_ENABLE_RTTI=ON \
      -DLLVM_ENABLE_TERMINFO=OFF \
      -DLLVM_ENABLE_ZLIB=FORCE_ON \
      -DLLVM_ENABLE_ZSTD=FORCE_ON \
      -DLLVM_DEFAULT_TARGET_TRIPLE=${HOST_TRIPLE} \
      -DLLVM_HOST_TRIPLE=${HOST_TRIPLE} \
      -DLLVM_INCLUDE_BENCHMARKS=OFF \
      -DLLVM_INCLUDE_DOCS=OFF \
      -DLLVM_INCLUDE_EXAMPLES=OFF \
      -DLLVM_INCLUDE_GO_TESTS=OFF \
      -DLLVM_INCLUDE_TESTS=ON \
      -DLLVM_INCLUDE_UTILS=ON \
      -DLLVM_INSTALL_UTILS=ON \
      -DLLVM_UTILS_INSTALL_DIR=libexec/llvm \
      -DLLVM_BUILD_LLVM_DYLIB=yes \
      -DLLVM_LINK_LLVM_DYLIB=yes \
      -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly \
      -DLLVM_BUILD_LLVM_C_DYLIB=ON \
      ../llvm

[h-vetinari]

Since the bot didn't tag any subscriber group here, I thought I'd do it by hand, but I actually cannot find a reasonable team for llvm overall, much less one specific to the shared libraries.

Based on the person who last touched the code referenced in the OP: @davidbolvansky, are you still working on llvm-c?

CC @tstellar @MaskRay @keith @jh7370 (based on people who are in several tools:llvm-* groups) perhaps you could help point me towards someone who cares about libllvm-c on osx?

[jh7370]

@h-vetinari, have you tried looking at the people who touch the llvm-c include folder? At a guess, those people might be able to help you, though I can't be certain.

[davidbolvansky]

Hello, I am not working in this area so I would not be able to help you :/

[MaskRay]

Not familiar with LLVM_BUILD_LLVM_C_DYLIB on macOS and can't help ...

[h-vetinari]

Thanks for your responses @jh7370, @davidbolvansky, @MaskRay

I don't have a use-case that's directly affected, so this isn't a burning issue (I repackage things, and someone wanted libllvm-c on windows, so it made sense to me to also build it on other platforms where it is ostensibly supported).

Still, it's IMO not a great look to have an documented & selectable option that just fails to build.

As suggested by @jh7370, some more CCs based on the recent commit history of include/llvm-c: @nikic @yamt @bogner