PDA

View Full Version : Mac linking to .dylib (resolving symbols @link time)



rickbsgu
1st March 2016, 21:39
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


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)


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



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


(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)


... 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
3rd March 2016, 19:48
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
4th March 2016, 07:42
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

rickbsgu
4th March 2016, 18:13
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
14th March 2016, 16:03
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
16th March 2016, 17:38
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
17th March 2016, 00:14
macdeployqt is what I use to embed the Qt framework libraries and plugins into my application bundles. Have you tried that?