[cfe-dev] Built Mavericks libclang.dylib Won't Link Out clang::FileManager

[support@goldencivet]

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!

> 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!