I can also confirm that this is an issue. I believe the problem is that the linker relies on the name mangling of the compiler, which is known to be unreliable for C++.Below is the runtime error I get on my code when I try to use the library on Mavericks (previously worked fine on Mountain Lion).dyld: lazy symbol binding failed: Symbol not found: __ZN10FileGDBAPI17DeleteGeodatabaseERKNSt3__112basic_stringIwNS0_11char_traitsIwEENS0_9allocatorIwEEEE
Referenced from: <file>
Expected in: flat namespace
dyld: Symbol not found: __ZN10FileGDBAPI17DeleteGeodatabaseERKNSt3__112basic_stringIwNS0_11char_traitsIwEENS0_9allocatorIwEEEE
Referenced from: <file>
Expected in: flat namespace
Below is the symbol of DeleteGeodatabase exported from the dylib:�?? nm -g libFileGDBAPI.dylib | grep DeleteGeodatabase
00000000000010b2 T __ZN10FileGDBAPI11Geodatabase17DeleteGeodatabaseEv
0000000000006260 T __ZN10FileGDBAPI17DeleteGeodatabaseERKSbIwSt11char_traitsIwESaIwEE
The dylib was created with GCC, which exported the symbol as:__ZN10FileGDBAPI17DeleteGeodatabaseERKSbIwSt11char_traitsIwESaIwEE
The new clang toolchain wants to link against that same symbol as:__ZN10FileGDBAPI17DeleteGeodatabaseERKNSt3__112basic_stringIwNS0_11char_traitsIwEENS0_9allocatorIwEEEE
Ideally, the FileGDB API should be exposed as a C API (like pretty much every other C++ library that offers binary linking). Exporting C++ from binaries makes for brittle linking problems like this, right?