claytonI'm having a tough time figuring out how to get TurboActivate working with a simple GUI application written with Qt Creator. I'm developing a cross-platform application, so whatever strategy I use, it needs to work for every platform. I found another thread on here describing problems with the Qt compiler so maybe I'm just fighting a loosing battle..
Since I'm on a mac at the moment, can anyone provide some guidance on how to include the .dylib with the Qt Creator project? I've placed libTurboActivate.dylib, TurboActivate.h (from the C++ example files), and TurboActivate.dat (downloaded from my account) in the project directory. In other words, those 3 files are in the same place as the Qt .pro, .h, .ui, and .cpp files. I haven't dealt a lot with external libraries, but from what I've read, I need to modify the .pro file to add the dylib library. I've added the following line at the top of my .pro file
LIBS += libTurboActivate.dylib
I also added #include "TurboActivate.h" in my main.cpp file. I have been getting a variety of errors as I try to troubleshoot through them. Such as...
Symbols not found for architecture x86_64
or
dyld: Library not loaded: @rpath/libTurboActivate.dylibReason: image not found
or a few others that all basically tell me that the library is not being successfully loaded. Can anyone provide some guidance here? You've got 1 more paying customer if I can figure it out 😀
Hey Clayton,
It sounds like your QT app doesn't have the correct search paths, and thus can't find the libTurboActivate.dylib file. This article describes how to do it with XCode. There are a couple of articles that describe how to do this with QT:
Tell me if that helps.
claytonOk so I did a lot of reading based on your links and experimented a lot more this morning. I was able to get the application to run in debug mode by placing the .dylib file in /usr/lib since that is apparently one of the default directories that the dynamic linker looks in (I believe that is based on the DYLD_LIBRARY_PATH environment variable on the mac and LD_LIBRARY_PATH on linux). When running otool I also saw that the bundle was looking for the file at @rpath/libTurboActivate.dylib. I have tried to alter that using the LIBS += "$$_PRO_FILE_PWD_/libTurboActivate.dylib" command in my .pro file, but that doesn't seem to work.
Things got a little trickier when I tried to use qtmacdeploy. I was seeing errors about not being able to find the .dylib file at /lib/libTurboActivate.dylib (note: different than /usr/lib), so I ended up creating that directory and placing the file there too. That allowed it to bundle fine and actually placed the .dylib file inside the mac .app bundle as well.
Essentially, at the moment, I am able to get the application to run fine in debug mode (apparently looking in /usr/lib for the .dylib). I can also bundle everything using qtmacdeploy (which places the .dylib file in the Contents/Frameworks directory), but when I run this bundled .app on another computer it fails because it is still looking for the file at @rpath/libTurboActivate.dylib.
It was my understanding that once macdeployqt got the .dylib copied into the bundle it would automatically change all the linker paths to look there. Is that not correct?
Disclaimer: I'm obviously new at this so take everything said above with a grain of salt.
Thanks in advance for the help!
claytonSmall update, I was able to get the final bundled .app to run using the name_change_tool utility. When I ran otool for the macdeployqt .app bundle, the output is below:
@rpath/libTurboActivate.dylib (compatibility version 1.0.0, current version 2.13.0) @executable_path/../Frameworks/QtOpenGL.framework/Versions/4/QtOpenGL (compatibility version 4.8.0, current version 4.8.1) @executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.1) @executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.1)
Clearly it was still looking in @rpath for the .dylib file. So the install_name_tool command to fix this was:
install_name_tool -change "@rpath/libTurboActivate.dylib" "@executable_path/../Frameworks/libTurboActivate.dylib" MyAppName
This was then consistent with the same paths used by the Qt libraries. Running otool again confirmed this. This is a massive pain to do each time I compile the application. I did some reading and I think the search path for each library is actually coded into the .dylib file itself. So in other words, if the libTurboActivate.dylib file was distributed with the install_name_tool tweak already applied to it, it would solve this problem from the start. Does anyone know if that is true? If so Wyatt, I might look into making that modification or at least ensuring that the linker search path hard coded into libTurboActivate.dylib is consistent with what other Mac libraries use.
The "@rpath/libTurboActivate.dylib" is the most flexible way to build TurboActivate. This way our customers can just modify the runpath search path of their executable (demonstrated here for XCode -- I don't know if QT Creator has something similar).
This was then consistent with the same paths used by the Qt libraries. Running otool again confirmed this. This is a massive pain to do each time I compile the application.
Add a build step to your app to do this automatically:
[attachment=0]Wj87Z.jpg[/attachment]
