Mac linking to .dylib (resolving symbols @link time)

[rickbsgu]

Well, it's been a while since I worked on Mac, and that was in the Carbon days.

So, I've created a nice little utility library (.dylib) and it looks fine. otool -D produces this:

libGenQtSupportLib.so.dylib:
libGenQtSupportLib.so.1.dylib

libGenQtSupportLib.so.dylib:
libGenQtSupportLib.so.1.dylib

To copy to clipboard, switch view to plain text mode 

so that looks nice, and the otool -L produces this:

libGenQtSupportLib.so.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	@rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.6.0, current version 5.6.0)
	@rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, current version 5.6.0)
	@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

libGenQtSupportLib.so.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	@rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.6.0, current version 5.6.0)
	@rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, current version 5.6.0)
	@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

To copy to clipboard, switch view to plain text mode 

and I think that looks ok. I'm not sure what the @rpath is, though...

So, now I'm trying to link to it, and the linker claims it can't find the library:

Here's the relevant part of my application .pro:

QT       += core gui
 
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
 
QMAKE_CXXFLAGS += "-std=c++11 -D__TESTING__"
QMAKE_CXXFLAGS_DEBUG += -O0
 
QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.7
 
TARGET = configPropertiesBundler
TEMPLATE = app
 
CONFIG += debug
 
GENQTSUPPORTLIBDIR = $$(DEV)/Qt/GenQtSupportLib
 
INCLUDEPATH += $${GENQTSUPPORTLIBDIR}
 
LIBS += -l$${GENQTSUPPORTLIBDIR}/libGenQtSupportLib.so.dylib

QT       += core gui

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets

QMAKE_CXXFLAGS += "-std=c++11 -D__TESTING__"
QMAKE_CXXFLAGS_DEBUG += -O0

QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.7

TARGET = configPropertiesBundler
TEMPLATE = app

CONFIG += debug

GENQTSUPPORTLIBDIR = $$(DEV)/Qt/GenQtSupportLib

INCLUDEPATH += $${GENQTSUPPORTLIBDIR}

LIBS += -l$${GENQTSUPPORTLIBDIR}/libGenQtSupportLib.so.dylib

To copy to clipboard, switch view to plain text mode 

What looks like the 'ld' command in the 'compile output' window is here:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -headerpad_max_install_names
-stdlib=libc++ -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
-mmacosx-version-min=10.7 -Wl,-rpath,/Users/Shared/devtools/qt5r/lib -o configPropertiesBundler.app/Contents/MacOS/configPropertiesBundler
main.o mainwindow.o OpenPropertiesBundleDialog.o moc_mainwindow.o moc_OpenPropertiesBundleDialog.o  
-F/Users/Shared/devtools/qt5r/lib
---> -l/Users/Shared/dev/Qt/GenQtSupportLib/libGenQtSupportLib.so <-----
-framework QtWidgets -framework QtGui -framework QtCore -framework OpenGL -framework AGL

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -headerpad_max_install_names
-stdlib=libc++ -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
-mmacosx-version-min=10.7 -Wl,-rpath,/Users/Shared/devtools/qt5r/lib -o configPropertiesBundler.app/Contents/MacOS/configPropertiesBundler
main.o mainwindow.o OpenPropertiesBundleDialog.o moc_mainwindow.o moc_OpenPropertiesBundleDialog.o  
-F/Users/Shared/devtools/qt5r/lib
---> -l/Users/Shared/dev/Qt/GenQtSupportLib/libGenQtSupportLib.so <-----
-framework QtWidgets -framework QtGui -framework QtCore -framework OpenGL -framework AGL

To copy to clipboard, switch view to plain text mode 

(note that my support lib name is truncated to '.so' without the '.dylib')

And the error output is:

ld: library not found for -l/Users/Shared/dev/Qt/GenQtSupportLib/libGenQtSupportLib.so
clang: error: linker command failed with exit code 1 (use -v to see invocation)

ld: library not found for -l/Users/Shared/dev/Qt/GenQtSupportLib/libGenQtSupportLib.so
clang: error: linker command failed with exit code 1 (use -v to see invocation)

To copy to clipboard, switch view to plain text mode 

... which is probably correct, given that it's looking for a '.so', even though I specified a '.so.dylib'

So, what am I missing? I'm sure the path is correct - the lib is really there. I've tried both the -L<path> -l<shortname> and the -l<fullname> variants and still get the same issue.

I guess I could create a '.so' link to the .dylib so it would find it, but that doesn't seem very proper.

(Note the question is re: link-time/symbol resolution time, not run-time.)

Any thoughts appreciated.

rickb

[rickbsgu]

Well, if I create a link '.so' without the .dylib extension to the .dylib (and use the -L<libpath> -l<libname> convention), it works.

Not getting the mac-specific lib naming convention correct.

[jefftee]

The dynamic libraries I have built/used on OSX just have the dylib extension, so for example, a library named Recode: /path/to/library/libRecode.dylib, I would use:

LIBS = -L /path/to/library -l Recode

LIBS = -L /path/to/library -l Recode

To copy to clipboard, switch view to plain text mode 

[rickbsgu]

Precisely - and that makes perfect sense, except that it's not working. It's looking for a '.so'

It's like it doesn't know it's on a mac. The QMAKESPEC variable is 'macx-clang', so that seems correct.

Might be my Qt build. I built in two separate locations - one for release (mainly for QtCreator) and one for debug (with the --developer switch turned on). Maybe I need to rebuild with 'debug-and-release' so that the debug libs have the '_debug' suffix and qt works better (at finding libs, anyway...)

Sigh. Would rather QtCreator didn't use my build libs. I can shove the current release libs into the QtCreator bundle so that it's standalone, I guess, & doesn't rely on my build libs... Kind of a PITA...

[rickbsgu]

Didn't have time to figure this out earlier, but now have re-focused attention on it, and...

...per usual, something dumb.

First some good news: the QtCreator build actually does install the needed frameworks in the bundle, so it is standalone and nothing needs to be done to make it so. That's good, in case I want to tweak the qt build and not affect qtc.

The issue: in my support lib .pro, I specified <libname>.so as the target. Which threw off the default library search mechanism. There is probably some permuted name I could use to get it, but the real answer is to just specify <libname> as the target, without the '.so' - and the normal resolution mechanism works fine.

So, I didn't really need to do the frameworks build, but I did, anyway. Might as well.

Onward...

[rickbsgu]

First some good news: the QtCreator build actually does install the needed frameworks in the bundle, so it is standalone and nothing needs to be done to make it so. That's good, in case I want to tweak the qt build and not affect qtc.

No it doesn't. bleah... banging along...

[jefftee]

macdeployqt is what I use to embed the Qt framework libraries and plugins into my application bundles. Have you tried that?