When building on macOS, you might encounter warnings like
ld: warning: response file
'__________________________________________________OOO/libAppleRemotelo.dylib'
could not be opened, errno=2 (No such file or directory)
while linking dynamic libraries like
[LNK] Library/libAppleRemotelo.dylib
S=/Users/sberg/lo/core && I=$S/instdir && W=$S/workdir && mkdir -p $W/Dep/LinkTarget/Library/ &&
RESPONSEFILE=/var/folders/8b/gn_n89wx2tx07th4vx34zgvw0000gn/T/gbuild.VnREoqc2xC && SYSTEM_BOOST=""
DYLD_LIBRARY_PATH=${DYLD_LIBRARY_PATH:+$DYLD_LIBRARY_PATH:}"$I/LibreOffice.app/Contents/Frameworks:$I/LibreOffice.app/Contents/Frameworks"
$W/LinkTarget/Executable/concat-deps ${RESPONSEFILE} > $W/Dep/LinkTarget/Library/libAppleRemotelo.dylib.d.tmp && rm -f ${RESPONSEFILE}
mv
/Users/sberg/lo/core/workdir/Dep/LinkTarget/Library/libAppleRemotelo.dylib.d.tmp
/Users/sberg/lo/core/workdir/Dep/LinkTarget/Library/libAppleRemotelo.dylib.d
S=/Users/sberg/lo/core && I=$S/instdir && W=$S/workdir && FILELIST=/var/folders/8b/gn_n89wx2tx07th4vx34zgvw0000gn/T/gbuild.8KQtO9E6uL && cat ${FILELIST} | tr "[:space:]"
"\n" | grep -v '^$' > ${FILELIST}.1 && mv ${FILELIST}.1 ${FILELIST} && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target arm64-apple-macos
-mmacosx-version-min=11.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.1.sdk -dynamiclib -install_name
'@__________________________________________________OOO/libAppleRemotelo.dylib' -fstack-protector-strong -L$W/LinkTarget/StaticLibrary -L$W/LinkTarget/Library -L$I/LibreOffice.app/Contents/Frameworks
-L$I/LibreOffice.app/Contents/Frameworks -Wl,-filelist,${FILELIST} -framework Cocoa -framework Carbon -framework IOKit -o $I/LibreOffice.app/Contents/Frameworks/libAppleRemotelo.dylib && rm -f ${FILELIST}
&& : && /usr/bin/perl $S/solenv/bin/macosx-change-install-names.pl shl OOO $I/LibreOffice.app/Contents/Frameworks/libAppleRemotelo.dylib && otool -l
$I/LibreOffice.app/Contents/Frameworks/libAppleRemotelo.dylib | grep -A 5 LC_ID_DYLIB > $W/LinkTarget/Library/libAppleRemotelo.dylib.exports.tmp &&
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm -g -P $I/LibreOffice.app/Contents/Frameworks/libAppleRemotelo.dylib | cut -d' ' -f1-2 | grep -v U$ >>
$W/LinkTarget/Library/libAppleRemotelo.dylib.exports.tmp && if cmp -s $W/LinkTarget/Library/libAppleRemotelo.dylib.exports.tmp $W/LinkTarget/Library/libAppleRemotelo.dylib.exports; then rm
$W/LinkTarget/Library/libAppleRemotelo.dylib.exports.tmp; else mv $W/LinkTarget/Library/libAppleRemotelo.dylib.exports.tmp $W/LinkTarget/Library/libAppleRemotelo.dylib.exports && touch -r
$I/LibreOffice.app/Contents/Frameworks/libAppleRemotelo.dylib $W/LinkTarget/Library/libAppleRemotelo.dylib.exports; fi && :
The reason is that, absent an explicit --enable-ld=... configuration
option (i.e., -fuse-ld=... compiler option), the default Xcode Apple
Clang compiler will use an Apple ld
(/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld),
which (as per `man ld`) supports some
Rarely used Options
@response_file_path
Inserts contents of file at response_file_path into arguments.
This allows for linker command line args to be store in a file.
Note: ld is normally invoked through clang, and clang also
interprets @file on the command line. To have clang ignore the
@file and pass it through to ld, use -Wl,@file.
And it looks like ld tries to interpret even the argument to the
-install_name as such a response file when that argument happens to
start with @. But it also looks like, after issuing that warning, it
then goes on to treat that @... command line argument as the
-install_name argument after all (presumably because it cannot open it
as a file), and all goes well. At least,
$ otool -L instdir/LibreOffice.app/Contents/Frameworks/libAppleRemotelo.dylib
instdir/LibreOffice.app/Contents/Frameworks/libAppleRemotelo.dylib:
@__________________________________________________OOO/libAppleRemotelo.dylib
(compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 24.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 170.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
(compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1356.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(compatibility version 45.0.0, current version 2685.20.119)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 4109.1.255)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 4109.1.255)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version
228.0.0)
shows that the right install_name was recorded in the generated dynamic
library, as intended.
So, absent any indications that this is an actual problem, I would
suggest that we keep living with this wart. (Otherwise, we'd probably
need to replace that @ that we use there with something else. Its use
was inspired by dyld's @executable_path etc. features. Trying to work
around the issue by passing the -install_name option as
-install_name=@... or -Wl,-install_name=@... on the compiler command
line would not work; there would rather be complaints about that option
being unknown.)
(This does not appear to be an issue with LLVM's ld64.lld, just with
Apple's own ld.)
