topic Re: OS X Mavericks in File Geodatabase API Questions

OS X Mavericks

JohnTull — Thu, 31 Oct 2013 21:15:01 GMT

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.

Re: File Geodatabase API 1.3 is now available for download.

LanceShipman — Thu, 31 Oct 2013 21:20:52 GMT

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.

Re: File Geodatabase API 1.3 is now available for download.

JohnTull — Thu, 31 Oct 2013 22:20:35 GMT

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.

Re: OS X Mavericks

JohnTull — Thu, 31 Oct 2013 22:23:17 GMT

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)

Re: OS X Mavericks

ZacMcCormick — Sat, 11 Dec 2021 06:56:44 GMT

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?

Re: OS X Mavericks

JohnTull — Wed, 06 Nov 2013 19:40:24 GMT

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.

Re: OS X Mavericks

ZacMcCormick — Sat, 11 Dec 2021 06:56:47 GMT

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 🙂

Re: OS X Mavericks

LanceShipman — Wed, 06 Nov 2013 22:38:13 GMT

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.

Re: OS X Mavericks

JohnTull — Thu, 07 Nov 2013 01:01:01 GMT

@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.

Re: OS X Mavericks

SimonNorris — Sat, 11 Dec 2021 06:56:50 GMT

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.

Re: OS X Mavericks

SimonNorris — Thu, 02 Jan 2014 21:08:41 GMT

ah, I see the problem. I just copied and pasted the install_name_tool commands. My fgdb files weren't in quite the right spot.

thanks again for posting the workaround @jctull !

Re: OS X Mavericks

SimonNorris — Sat, 11 Dec 2021 06:56:52 GMT

Actually, after fixing the paths in the install_name_tool commands I'm still having problems.
I'm not sure how to debug this.

I'm using this method to get fgdb support in gdal:
http://blog.burhum.com/post/34851795066/installing-gdal-ogr-with-filegdb-support-on-osx-with

I copy the api lib and include files to /usr/local/lib /usr/local/include and install gdal no problem, the FileGDB format is recognized by ogrinfo. And it looks like the install_name_tool commands successfully change the gcc reference:

$ 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/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/lib/libfgdbunixrtl.dylib

$ otool -L libFileGDBAPI.dylib
libFileGDBAPI.dylib:
 @rpath/libFileGDBAPI.dylib (compatibility version 0.0.0, current version 0.0.0)
 @rpath/libfgdbunixrtl.dylib (compatibility version 0.0.0, current version 0.0.0)
 /usr/local/Cellar/gcc49/4.9-20131103/lib/gcc/x86_64-apple-darwin13.0.0/4.9.0/libstdc++.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
libfgdbunixrtl.dylib:
 @rpath/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/local/Cellar/gcc49/4.9-20131103/lib/gcc/x86_64-apple-darwin13.0.0/4.9.0/libstdc++.dylib (compatibility version 7.0.0, current version 52.0.0)

but still no luck using the api:

$ ogrinfo Misc.gdb
ogrinfo(81745,0x7fff797e2310) malloc: *** error for object 0x10d219de0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

Re: OS X Mavericks

SimonNorris — Sat, 11 Dec 2021 06:56:55 GMT

For my purposes (just using the api with a homebrewed ogr/gdal for data conversions) @dakcarto's gdal-filegdb formula works fine without dealing with compiler issues. Installing the api as a plugin seems to be the key.

https://github.com/dakcarto/homebrew-osgeo4mac/issues/8

# Place FileGDB_API_1_3-64.zip archive in GDAL_THIRD_PARTY directory 
export GDAL_THIRD_PARTY=  #/path/to/gdb-api-zipfile
brew install gdal --enable-unsupported --with-postgresql
brew tap dakcarto/osgeo4mac
brew install gdal-filegdb
export GDAL_DRIVER_PATH=  #{HOMEBREW_PREFIX}/lib/gdalplugins

Re: OS X Mavericks

Celeste_SuliinBurris — Sun, 30 Mar 2014 01:40:11 GMT

I can't build GDAL with the File GDB API. I'm leary of installing Homebrew, because all my stuff was built by hand, and goodness knows what it would break. ESRI - Please fix!

Re: OS X Mavericks

PaulAustin — Fri, 30 May 2014 17:36:13 GMT

On Mavericks you can use clang++ instead of g++ with the following options for compiling and linking. That way you don't need to change the library locations using libtool.

-stdlib=libstdc++ -mmacosx-version-min=10.6

I got this from the following page.

https://support.enthought.com/entries/26184115-GCC-Clang-and-Cython-in-OS-X-10-9-Mavericks

Re: OS X Mavericks

ChristinaGutierrez — Sat, 11 Dec 2021 06:56:58 GMT

For my purposes (just using the api with a homebrewed ogr/gdal for data conversions) @dakcarto's gdal-filegdb formula works fine without dealing with compiler issues. Installing the api as a plugin seems to be the key.

https://github.com/dakcarto/homebrew-osgeo4mac/issues/8
# Place FileGDB_API_1_3-64.zip archive in GDAL_THIRD_PARTY directory 
export GDAL_THIRD_PARTY=  #/path/to/gdb-api-zipfile
brew install gdal --enable-unsupported --with-postgresql
brew tap dakcarto/osgeo4mac
brew install gdal-filegdb
export GDAL_DRIVER_PATH=  #{HOMEBREW_PREFIX}/lib/gdalplugins

This worked perfectly for me with homebrewed gdal & gdal-filegdb installs -- thanks. Was the only thing that did.
$ ogrinfo --formats
Supported Formats:
-> "FileGDB" (read/write)
...