Path length limitations with clang++ linker

I’m facing an odd behavior running Apple clang (13.0.0 (clang-1300.0.29.30).

The following command produced no output:

$ clang++ \
-shared \
-Wl,-install_name,liblldb-java.dylib \
-L/usr/local/Cellar/llvm/13.0.1_1/lib \
-llldb \
-m64 \
-o /usr/local/Caskroom/ghidra/10.1.2-20220125/ghidra_10.1.2_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/os/mac_x86_64/liblldb-java.dylib \
/usr/local/Caskroom/ghidra/10.1.2-20220125/ghidra_10.1.2_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/objs/main/shared/mac_x86_64/mainCpp/b6954r4kxxfhmnzbfiaa1erun/LLDBWrapJava.o

However, if I move the LLDBWrapJava.o such that its path gets shorter (e.g. /tmp/LLDBWrapJava.o) and then run it like so:

$ cd /tmp
$ clang++ \
-shared \
-Wl,-install_name,liblldb-java.dylib \
-L/usr/local/Cellar/llvm/13.0.1_1/lib \
-llldb \
-m64 \
-o liblldb-java.dylib \
LLDBWrapJava.o

It does produce the shared library.

Neither command output any warnings, both exit with 0. I’m running this in Apple’s Terminal.app and my shell is bundled zsh (5.8):

$ getconf ARG_MAX
1048576

MAX_ARG_STRLEN is, apparently, 1046597

AppleClang and Clang is different in quite a few ways, can you download the binaries from llvm.org and try to replicate the problem there? If it still fails - try adding -fuse=lld to use lld instead of ld64 - this should work fine with LLVM 14.x.

Another tip is to add -Wl,-v to get verbose output from lld.

Atm I have tried the same command with clang++ from 13.0.1 (installed via homebrew), same result:

$ /usr/local/Cellar/llvm/13.0.1_1/bin/clang++ \
-shared \
-Wl,-install_name,liblldb-java.dylib \
-Wl,-v \
-L/usr/local/Cellar/llvm/13.0.1_1/lib \
-llldb \
-m64 \
-o "/usr/local/Caskroom/ghidra/10.1.2-20220125/ghidra_10.1.2_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/os/mac_x86_64/liblldb-java.dylib" \
"/usr/local/Caskroom/ghidra/10.1.2-20220125/ghidra_10.1.2_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/objs/main/shared/mac_x86_64/mainCpp/b6954r4kxxfhmnzbfiaa1erun/LLDBWrapJava.o" \
--verbose

Homebrew clang version 13.0.1
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /usr/local/Cellar/llvm/13.0.1_1/bin
 "/usr/bin/ld" -demangle -lto_library /usr/local/Cellar/llvm/13.0.1_1/lib/libLTO.dylib -dynamic -dylib -arch x86_64 -platform_version macos 11.0.0 11.0.0 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -o /usr/local/Caskroom/ghidra/10.1.2-20220125/ghidra_10.1.2_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/os/mac_x86_64/liblldb-java.dylib -L/usr/local/Cellar/llvm/13.0.1_1/lib -install_name liblldb-java.dylib -v -llldb /usr/local/Caskroom/ghidra/10.1.2-20220125/ghidra_10.1.2_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/objs/main/shared/mac_x86_64/mainCpp/b6954r4kxxfhmnzbfiaa1erun/LLDBWrapJava.o -lc++ -lSystem /usr/local/Cellar/llvm/13.0.1_1/lib/clang/13.0.1/lib/darwin/libclang_rt.osx.a
@(#)PROGRAM:ld  PROJECT:ld64-711
BUILD 21:57:11 Nov 17 2021
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
	/usr/local/Cellar/llvm/13.0.1_1/lib
	/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/lib
Framework search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/System/Library/Frameworks/

And if you try with lld?

I wish I could delete this thread. Both frontend worked well, it was me who missed a tiny difference in these longs paths and I was looking for a binary in wrong place :slight_smile:

2 Likes

At least it’s solved! Good!