OS X Mavericks

[JohnTull]

It appears that the available binary API is not compatible with the new OS X 10.9 Mavericks. Can anyone else confirm or deny this? I am unable to build gdal support for FileGDB, and I suspect it is due to changes in the available libs in 10.9 versus older OS versions.

[LanceShipman]

It appears that the available binary API is not compatible with the new OS X 10.9 Mavericks. Can anyone else confirm or deny this? I am unable to build gdal support for FileGDB, and I suspect it is due to changes in the available libs in 10.9 versus older OS versions.

We will take a look. Can you provide more information. What errors are you seeing when you attempt to build gdal.

[JohnTull]

We will take a look. Can you provide more information. What errors are you seeing when you attempt to build gdal.

There is no output other than a failure to pick up the FileGDB API during the configuration step, despite having the libs and includes in the correct locations that worked in 10.8.

"checking for FileGDBAPI... FileGDBAPI not found."

These are the steps I followed prior to 10.8 and that I repeated for 10.9 to formerly get FileGDB support in gdal builds:

unzip FileGDB_API*.zip
mv FileGDB_API /usr/local/opt
cd /usr/local/include
ln -s ../opt/FileGDB_API/include/* .
cd ../lib
ln -s ../opt/FileGDB_API/lib/lib* .
cd ../opt/FileGDB_API
install_name_tool -id "$(pwd)/lib/libFileGDBAPI.dylib" ./lib/libFileGDBAPI.dylib
install_name_tool -change "@rpath/libfgdbunixrtl.dylib" "$(pwd)/lib/libfgdbunixrtl.dylib" ./lib/libFileGDBAPI.dylib
install_name_tool -id "$(pwd)/lib/libfgdbunixrtl.dylib" ./lib/libfgdbunixrtl.dylib

...
Proceed to configure and build gdal from source.

[JohnTull]

otool reports that FileGDB is built agains libstdc++, but 10.9 uses clang with libc++ support. I believe this is where the incompatibility lies and that a 10.9 specific version might need to be built.

otool -L libFileGDBAPI.dylib                                                                                                   16:20:55  �?�  master �?? �??
libFileGDBAPI.dylib:
/usr/local/opt/FileGDB_API/lib/libFileGDBAPI.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/FileGDB_API/lib/libfgdbunixrtl.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

otool -L libfgdbunixrtl.dylib                                                                                                  16:21:02  �?�  master �?? �??
libfgdbunixrtl.dylib:
/usr/local/opt/FileGDB_API/lib/libfgdbunixrtl.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)

[ZacMcCormick]

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?

[JohnTull]

Thanks, zacmcc. Because you're a developer, your feedback is very helpful. I'm not a dev and was left with guesswork from my limited knowledge on how to debug the issue.

I'm hopeful that a solution can be developed soon.

[ZacMcCormick]

I forgot to mention... I was able to get the library to work on Mavericks after some head banging.

Apple removed llvm-gcc in Mavericks, so you just need to install GCC manually and programs can link against the FileGDB dylib.

$ brew tap homebrew/versions
$ brew install --enable-cxx gcc49

Then you can use the 'gcc-4.9' command to compile and it should work.

It is documented in the README that you need GCC, but it's still unfortunate that the library requires a specific compiler. Consider this my vote for a supported C API 🙂

[LanceShipman]

Thank you for all of the feedback on the file geodatabase API and OS X Mavericks. We are investigating our options and will be providing a solution as part of the next release of the API. The release date has not be set, but I expect it will be before the ESRI Dev Conference in March.

[JohnTull]

@zacmcc
Thanks for figuring out a way to make this work. I recompiled my gdal via homebrew, supplied the additional option cc='gcc-4.9' with my brew command, and all is good!

Additionally, I had to run install_name_tool on the FileGDB libs to link them to the gcc49 libstdc++.dylib:

install_name_tool -change /usr/lib/libstdc++.6.dylib /usr/local/Cellar/gcc49/4.9-20131103/lib/gcc/x86_64-apple-darwin13.0.0/4.9.0/libstdc++.dylib /usr/local/opt/FileGDB_API/lib/libFileGDBAPI.dylib

install_name_tool -change /usr/lib/libstdc++.6.dylib /usr/local/Cellar/gcc49/4.9-20131103/lib/gcc/x86_64-apple-darwin13.0.0/4.9.0/libstdc++.dylib /usr/local/opt/FileGDB_API/lib/libfgdbunixrtl.dylib

After that, my custom gdal was able to build and support FileGDB in OS X 10.9 Mavericks!

If anyone is interested in this, I have some notes on OS X Mavericks, gdal, the FileGDB fix and additional dependency notes to get QGIS running here:
https://gist.github.com/jctull/f4d620cd5f1560577d17

Those are likely to become outdated, but were current for me as of 6 Nov 2013.

@lshipman
Thanks for committing to an ESRI solution. I'm glad we managed a workaround that won't require that long of a wait.

[SimonNorris]

Thanks for posting these suggestions. Using the method outlined I've managed to now get my homebrew installed gdal to recognize the file-geodatabase-api format, but I get this error message when pointing to a valid .gdb:

ogrinfo(45386,0x7fff74779310) malloc: *** error for object 0x10b49dde0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

I'm not too sure what to do with this error message. Any tips are much appreciated.
My script setting up gdal is here.