1

I am working on a shell script to run qmake commands to build a project on OSX.

I was getting this error after updated to Xcode 7.1.2 (which I had to do because nothing would build at all after upgrading to yosemite before I updated XCode):

    Undefined symbols for architecture x86_64:
  "__Unwind_Resume", referenced from:

It turns out that qmake was generating a makefile with the flag -mmacosx-version-min=10.5 and changing that with sed to 10.9 did the trick.

But, now I have a problem caused by linking to 4 or 5 boost libraries (got with homebrew) and another dynamic library (libbar64.dylib) that I wrote. Here is the stripped down version of the build script: 

#!/bin/bash
PROJECT="foo"

# to find the dylib
install_name_tool -id "@executable_path/../Resources/libbar64.dylib" 

# moc and uic
$QMAKEPATH/uic mainwindow.ui -o ui_mainwindow.h
$QMAKEPATH/moc mainwindow.h -o moc_mainwindow.cpp

# library paths and libs
libpath="-L/usr/local/Cellar/boost/1.59.0/lib/ -L/usr/local/lib -L./"
libs="-lbar64 -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -lboost_iostreams-mt -lboost_exception-mt -lboost_filesystem-mt"

# make pro file
$QMAKEPATH/qmake -project
echo 'LIBS +=' $libpath $libs >> $PROJECT.pro

# generate the makefile
$QMAKEPATH/qmake -spec macx-g++ $PROJECT.pro

# kludge
sed -i -e 's/min=10.5/min=10.9/g' Makefile

# make it
make
# put libbar into the resources folder
cp ./libbarl64.dylib $PROJECT.app/Contents/Resources/

The problem arises because the shared boost libraries aren't known to foo after its built. I could set DYLD_LIBRARY_PATH to the boost directory /usr/local/Cellar/boost/1.59.0/lib/ but I don't want to do that (because of this).

I tried to change my libs variable to:

libs="-shared -lbar64 -static -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -lboost_iostreams-mt -lboost_exception-mt -lboost_filesystem-mt"

But now I get the 

Undefined symbols for architecture x86_64:
  "__Unwind_Resume", referenced from:

error again. Does anyone know how to get around this without swapping environment variables? I never had problems of this kind until the latest OSX updates. I want to link to boost statically, but it seems be in opposition with libgcc_eh.a libarary for some reason. I hate it when Apple updates break my build scripts.

Community
  • 1
  • 1
dmedine
  • 1,430
  • 8
  • 25
  • Are the libraries built 64-bit? – Kurt Stutsman Mar 18 '16 at 00:57
  • AFAICT. What puzzles me is that I don't get this error when I link to boost dynamically, but do get it when I link statically. The two versions of the library were both obtained via homebrew and sit in the same directory. – dmedine Mar 18 '16 at 16:49
  • Maybe try specifying the full path to the 64-but libraries instead of `-llib`. If that works you might need to add something like -m64 somewhere on the command line. – Kurt Stutsman Mar 18 '16 at 16:51
  • I'm starting to think that libgcc_eh.a is in fact not the right architecture. I don't really know how to go about correcting this in Mac-land. – dmedine Mar 18 '16 at 17:28

0 Answers0