Built Mavericks libclang.dylib Won't Link Out clang::FileManager

Clang Frontend
1

Hey there.

So after an apparently successful vanilla trunk build on Mavericks [--enable-libcpp --enable-keep-symbols] a trivial main instantiating FileManager fails to link out against libclang.dylib.

The xcodebuild link:

XCODE_DEV/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot XCODE_DEV/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -LTRIVIAL/Build/Products/Debug -LLLVM_PROJECT/llvm/projects/libcxx/lib -LLLVM_PROJECT/build/Debug+Asserts/lib -FTRIVIAL/Build/Products/Debug -filelist TRIVIAL/Build/Intermediates/Objects-normal/x86_64/TRIVIAL.LinkFileList -mmacosx-version-min=10.9 -nostdlib -stdlib=libc++ -fobjc-link-runtime -lc++.1 -lSystem -framework Foundation -framework AppKit -Xlinker -dependency_info -Xlinker TRIVIAL/Build/Intermediates/Objects-normal/x86_64/TRIVIAL_dependency_info.dat -o TRIVIAL/Build/Products/Debug/TRIVIAL

Fails to find FileManager's constructor:

Undefined symbols for architecture x86_64:
  "clang::FileManager::FileManager(clang::FileSystemOptions const&)", referenced from: _main in main.o
ld: symbol(s) not found for architecture x86_64

Which mangled is:

$ nm main.o | egrep clang11FileManagerC
                 U __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE

Where things get vexing is that the dylib apparently defines it as expected:

$ nm libclang.dylib | egrep __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
0000000000e3bf00 t __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE

Presumably in its role as "umbrella" over libclangBasic.a:

nm libclangBasic.a | egrep __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
0000000000000060 T __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
0000000000068a58 S __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE.eh

So why ain't it found?

ld's link (as opposed to runtime) decision-making is pretty opaque. There didn't seem to be any way to get more verbose detail on how the dylib might be "failing."

Any suggestions?

Thanks!

2

Unfortunately the due diligence of "make install" was no help. With these link switches:

-arch x86_64
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-LBUILD/Products/Debug
-LLLVM_INSTALL/lib
-FBUILD/Products/Debug
-filelist BUILD/Intermediates/.../TRIVIAL.LinkFileList
-mmacosx-version-min=10.9
-nostdlib
-stdlib=libc++
-fobjc-link-runtime
-lclang
-lc++.1
-lSystem
-framework Foundation
-framework AppKit
-Xlinker -dependency_info
-Xlinker BUILD/Intermediates/.../TRIVIAL_dependency_info.dat
-o BUILD/Products/Debug/TRIVIAL

Same problem:

   Undefined symbols for architecture x86_64:
   "clang::FileManager::FileManager(clang::FileSystemOptions const&)", referenced from:
   _main in main.o
   ld: symbol(s) not found for architecture x86_64

Despite its apparent presence:

   $ nm -m BUILD/main.o | egrep clang11FileManagerC
   (undefined) external __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE

   $ nm -m LLVM_INSTALL/lib/libclang.dylib | egrep __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
   0000000000e3bee0 (__TEXT,__text) non-external (was a private external) __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE

   $ nm -m LLVM_INSTALL/lib/libclangBasic.a | egrep __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
   0000000000000060 (__TEXT,__text) external __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
   0000000000068a58 (__TEXT,__eh_frame) external __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE.eh

   $ nm -m LLVM_INSTALL/lib/libclang.a | egrep __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
   (undefined) external __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
   (undefined) external __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
   (undefined) external __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE

   $ nm -m LLVM_INSTALL/lib/libclangBasic.a | egrep __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
   0000000000000060 (__TEXT,__text) external __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE
   0000000000068a58 (__TEXT,__eh_frame) external __ZN5clang11FileManagerC1ERKNS_17FileSystemOptionsE.eh

Back when we were using ASTConsumer we wound up just compiling the whole source tree into our binary.

Looks like we'll be resorting to that mess again as we can apparently neither adopt the Cupertino-installed edition nor link against the unmodified trunk.

Not for nothing, but a wee hack leveraging the same compiler as the OS and its IDE seems more painful than it should be!

Thanks!

3

Explicit library roulette eventually yields a winner:

-arch x86_64
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-LBUILD/Products/Debug
-LLLVM_INSTALL/lib
-FBUILD/Products/Debug
-filelist BUILD/Objects-normal/x86_64/TRIVIAL.LinkFileList
-mmacosx-version-min=10.9
-nostdlib
-stdlib=libc++
-fobjc-link-runtime
-lcurses
-lclangAnalysis
-lclangAST
-lclangBasic
-lclangDriver
-lclangEdit
-lclangFrontend
-lclangLex
-lclangParse
-lclangSema
-lclangSerialization
-lLLVMBitReader
-lLLVMCore
-lLLVMMC
-lLLVMMCParser
-lLLVMOption
-lLLVMSupport
-lLLVMTransformUtils
-lc++.1
-lSystem
-framework Foundation
-framework AppKit
-Xlinker -dependency_info
-Xlinker BUILD/Intermediates/…/Objects-normal/x86_64/TRIVIAL_depe...
-o BUILD/Products/Debug/TRIVIAL

So it would seem we must be horking that dylib somehow.

Thanks!

4

This is the correct way of liking in order to use the C++ interface.
Link to libclang.dylib only if you use the C interface.

Dmitri

5

Right. libclang exports a truly stable (C) API. None of the C++ entry points in Clang or LLVM are considered LLVM, and they are not exposed in the libclang dynamic library.