I've got an application project that depends on a couple of shared libraries that I have created myself. According to the Qt 4.6 documentation "Deploying an Application on Mac OSX":
Note: If you want a 3rd party library
to be included in your application
bundle, then you must add an excplicit
lib entry for that library to your
application's .pro file. Otherwise,
the macdeployqt tool will not copy the
3rd party .dylib into the bundle.
I have added lib entries to my application's .pro file but the libraries that I have written do not get copied into the bundle when I execute macdeployqt. I have the following in my .pro file:
LIBS += -L../Libraries -lMyLib
Everything builds okay, its just when I try to run from the bundle that I run into problems i.e. "image not found" errors.
Is there a bug in macdeployqt or do I have to something more to my .pro file?
badcat is correct that the Qt 4.6 documentation has a grossly inflated view of what is possible with macdeployqt tool.
In my experience, the only things that are done by macdeployqt are:
Copy the Qt libraries into your app bundle in the foo.app/Contents/Frameworks/ directory
Adjusts the link libraries of one binary, namely foo.app/Contents/MacOS/foo (must have same name as app bundle, even if you mention another binary in Info.plist)
So, for every other binary and library you want to deploy in your app bundle, you must do the following:
Run macdeployqt to enjoy its useful but feebly inadequate benefits
macdeployqt <path_to_your_nascent_app_bundle>/foo.app
Install your extra libraries manually
cp <original_library_path> foo.app/Contents/Frameworks/<lib_name>
Find out what libraries each binary links to.
otool -L <binary_file_name>
Change the internal libary paths in your binaries
install_name_tool -change <original_library_path> #executable_path/../Frameworks/<lib_name> <binary_file_name>
I wrote a perl script that automates these steps for my application, but it's a bit too specific to my particular environment to post here.
You don't need to take care about manual deployment of third-party libraries. I am uploading a patch to Qt that makes it possible to specify additional library search paths, so that the macdeployqt tool finds the third-party dependencies:
https://codereview.qt-project.org/#change,47906
After this one there will be another commit that will add support for third party libraries' deployment.
Did you check the .app bundle to see if the libraries are really not there?
If that's the case, I'd assume there really is a bug in macdeployqt, or it simply can't find the library you are linking. Personally I've never seen macdeployqt actually copy any needed 3rd-party libraries into the bundle.
The interesting part is that macdeployqt never ever works directly with the .pro file. It just does some stuff to the produced application bundle. And after a quick glance into the documentation this Qt 4.7 documentation page obviously proves me right:
Note: If you want a 3rd party library to be included in your application bundle, then you must copy the library into the bundle manually, after the bundle is created.
I'd assume there is a bug in the 4.6 documentation. For me macdeployqt never placed any library files in my bundle (except for the Qt* ones, of course).
I did spend a lot of time with this stuff in my past, and ended up writing a simple little (Python) script that packs everything up into my bundle, changes the library names as needed and puts everything in a .dmg file with automatic naming.
Possibly not what you wanted to hear, but it works. ;)
https://github.com/auriamg/macdylibbundler
dylibbundler is a small command-line programs that aims to make bundling .dylibs as easy as possible. It automatically determines which dylibs are needed by your program, copies these libraries inside the app bundle, and fixes both them and the executable to be ready for distribution... all this with a single command on the teminal! It will also work if your program uses plug-ins that have dependencies too.
Related
I write applications in C++/Qt, and sometimes I have to compile them in Windows. For that I use MinGW. Unfortunately, that makes the executable dependant on mingwm10.dll and libgcc_s_dw2-1.dll. I prefer to solve such problems by just copying needed DLLs into application folder and distributing it like this. I use QMAKE_POST_LINK in the *.pro file to automate the process.
Unfortunately, for various reasons MinGW ends up in different directories on different systems I use. Is there a way to get the path to the compiler executable in Qt project? MinGW libs lie near its exe, so it would solve the problem.
Thanks.
UPDATE
I'm afraid I didn't put myself clear enough.
I know that 90% of users don't have Qt, and 99% don't have MinGW installed on their Windows desktop. This is why I distribute all needed DLLs along with the executable, so that it can run everywhere without installing anything. I just copy them in the same folder with the *.exe. To automate this copying process, I add a copy command to the QMAKE_POST_LINK, which executes it after the linker finishes linking my program.
The problem is that this copy command still needs to know from where to copy MinGW libraries. Hence my question: how can one know the compiler path in compile time?
$$OUT_PWDin Qt *.pro file expands to the path to the directory where built application is put to. $$PWD expands to the project directory. Is there a similar macro (or maybe a hack) which gives the path to the compiler executable?
You are trying to approach the problem from the wrong angle. In particular, the solution you want will not be robust. It will still break on different systems, for example, the ones that have different version of MinGW toolchain installed and therefore different runtime DLLs, which if loaded by your application (built with another version of MinGW) will most probably cause crashes and undefined behavior during runtime. Furthermore, there might be systems which do not even have MinGW installed. These are the main reasons why applications built with certain version of toolchain should be distributed with the corresponding runtime DLLs included (this is what is called redistributable runtime) which is common practice on Windows, and there is nothing wrong with it.
However, there is much better way to solve your problem. Simply link all the MinGW runtime libraries statically into your application. This is a very good practice for Windows applications (and a very bad one for Unix ones). To do that, add the following to the corresponding *.pro:
QMAKE_LFLAGS_WINDOWS += -static-libgcc -static-libstdc++ -static
NOTE: Qt libraries themselves have to be built with these flags too, i.e. they should be independent of the MinGW runtime too. If not, then you'd still have a transitive dependency to the MinGW runtime because of the Qt libraries your application is linked against.
NOTE: _WINDOWS suffix will ensure that your application gets linked with these flags only for the Windows platform, while on Unix it will still link dynamically with runtimes (such as glibc.so on Linux) for the reasons discussed above.
After that your application will no longer explicitly depend on any MinGW runtime DLLs what will solve both distribution and maintenance headaches.
NOTE: If you ever decide to migrate from QMake to CMake (recommended), then here's how you do the same for CMake.
Update
You could check the QMAKE_CXX variable, but most likely it does not contain an absolute path to g++.exe. Usually it is simply g++, and the directory containing it is searched in PATH then. So in this case you'd have to parse PATH and check each directory in it for existence of g++ in it. This is very nasty logic to write in such a limited build system as QMake. So, as I stated above, you better off with 2 options:
Link runtimes statically into the application, so that you don't have to distribute anything. If you don't want to do it, then I want to know why - please write a comment;
Migrate to more feature-rich and flexible build system - CMake.
I have a CMake project for a Qt based application using plugins.
The standard way to create a plugin is CMake (on all platforms) is with:
ADD_LIBRARY(${PROJECT_NAME} MODULE ...)
This creates a libxxx.so plugin (instead of a libxxx.dylib, if SHARED is used instead of MODULE above).
Now, when running inside an IDE like Xcode or QtCreator, the application works fine, the plugin is loaded and works.
But if I create the .app bundle, the application does not start, saying "libxxx.so is not a valid Qt plugin"! How could be that possible? Maybe some library dependency is not found, but how can i check that? I have used tool -L and I think all the libraries are ok.
You may need a "qt.conf" file in your bundle to tell Qt where the plugins are.
You should read up on CMake's BundleUtilities fixup_bundle function and let it do all that "otool -L" and "install_name_tool" stuff for you.
See this recent related stackoverflow question and answer:
CMake: Copy Frameworks into App Bundle
I'm trying to deploy an application using macdeployqt. All Qt frameworks get copied correctly into the application bundle. The problem I encounter is that macdeployqt does not have write permissions on the copied frameworks which originally reside in /usr/local/lib. This is because I have installed qt using homebrew which seems to make install everything read only. My question is whether there is a better way to fix this issue then manually changing all permissions of the qt libraries inside /usr/local/lib so that I can use macdeployqt from within a qt .pro project. (I don't want to use macdeployqt manually with sudo or such)
The reason why I'm asking is because I am using many third party libraries in the project (they get copied ok etc.) which I need to update often through homebrew and thus have to redo the permission changing on them.
Thanks in advance!
Just in case someone finds this old post looking for info about macdeployqt:
Use a script to do macdeployqt in preference to scripting the macdeployqt commands in your .pro file. That will allow you to change the permissions on the files on the fly.
Here is [a snippet of] the script I use for one of my apps:
https://bugreports.qt-project.org/browse/QTBUG-23268
If you're on Windows and don't have bash, you can use perl or python. The script referenced above modifies the files on the fly to work around a bug - you can put anything you want here, including changing the permissions on the files.
Using a script also means that you have the flexibility to add commands later to do code-signing, packaging or whatever else you need.
The Qt .pro "scripting language" actually generates Makefile commands under the hood and can be quite obscure if you want to accomplish deployment tasks that relate to paths and sets of files.
Also you'll need to create an extra target or include it into your build target - either way the build process becomes more complex and more error prone.
Disclaimer: I worked on Qt for 8 years as a Senior Engineer for Nokia/Trolltech, and also have published a commercial cross-platform app using Qt.
I was successfully able to compile and run my Qt application. However, when I move the .exe file outside its original path, I found out that I have to manually copy the Qt DLLs (e.g. mingw10.dll, qtcore4.dll). Is there any dynamic way to link these libraries with my application?
I think you mean you want to "statically" link these libraries with your application.
Basically this means that everything will be rolled inside your exe, and you will have no need of those dlls anymore.
There are advantages to to static linking, but there are also disadvantages as well. You should be absolutely sure that this is what you want to do before you go this way.
Check out this link which explains the difference in depth Dynamic Linking vs Static Linking
As for your specific issue, if you are sure you want to use static linking you will have to change your Qt setup to be built statically. By default the Qt distribution is setup to use dynamic linking. There is a handy guide for that here.
Basically when you setup the build you have to run "configure -static" to change all the project settings to use static linking instead of dynamic linking. And then build Qt over again.
You should also verify your Qt license. If you are using the Qt LGPL license and you want to to link statically you will have to include all your object files (.o and .obj) as Mihai Limbășan wisely explained in his comment. If you have bought and paid for Qt, then you have no problem.
If the DLLs are on the PATH for the application, then they will be found and work. So, you could add where your Qt binaries/dlls are into the %PATH% environment variable. If you're going to create an installer for your application, you'll need to either package these libraries in so they're in the bin directory - or you'll have to expect every user to install and possibly compile Qt themselves (hint: go with the first option. :) )
Whats the best way to deploy a QT app? I've read the documentation hosted at trolltech but is it better to link with a static library or the dynamic libraries and have the user install the framework? I don't really want anyone using my app to have to download a 160mb framework just to run a simple gui frontend.
On OS X it's a good way to do a dynamic build and post-process the resulting ".app" with the macdeployqt tool which comes with Qt starting with 4.5.
This will copy the Qt frameworks used by your application into the application bundle, which results in a larger package than building a static version of your application.
Here is what you can do to make sure you get the smallest file size possibly in a dynamic build:
First off, make sure you only include the stuff you need (in the project.pro file's QT += core gui network xml lines).
Open the application bundle and remove any unneeded "Qt Plugins" from the bundle. macdeployqt automatically compies all the Qt plugins in there, which can be kind of bulky.
Make sure you are building your application in release mode. Otherwise your application might be linked against the debug libraries of the Qt4 framework, and they are really big (for instance, well over 90 MB for the debug library vs. 16 MB of a release variant without debugging symbols). This might be what happened in your case.
If you have a large application binary, you can use UPX to compress your executable file by 40-50%.
Other than that, you should use compressed disk images to deploy your application.
One of my projects uses QtGui, QtNetwork, QtCore and QtXml and the resulting bundle is about 16 MB in size.
Hope that helps.
Unfortunately you will have to include the Qt libraries you need into your own bundle, as you cannot expect your users to have Qt installed on Mac (whereas on Linux packaging systems allow you to require at least a given version of Qt.
There is a nice tool to help you with that, which is called macdeployqt. You just need to invoke it on your bundle application and it will pack the required libraries, changing the linkage of your binary to refer to them. Without it, making bundles for Mac is a real pain (it still is, but considerably less though).
http://doc.trolltech.com/4.6/deployment-mac.html#the-mac-deployment-tool
Afterwards, you can make a .dmg image as you would do with any other app. There is an option in macdeployqt that builds a basic one.
On Linux, it's better to rely on the OS's copy of Qt, as it's almost certainly installed - for OS X, almost all apps use a statically compiled library.