On Feb 10, 2015, at 7:52 AM, René J.V. Bertin <rjvber...@gmail.com> wrote:
>> >> Em Tue Feb 10 2015 at 4:32:58 AM, Thiago Macieira <thiago.macie...@intel.com> >> escreveu: >> > >>> That must be the same MacPorts leak issue. > > Yep. The "funny" part of that issue is that Qt's own binaries are generated > with a HUGE "rpath" stored in them, which makes it possible to install the > distribution just about anywhere and still have enough margin to edit those > paths with a simple binary file editor (you can shorten static strings by > putting a nullbyte somewhere, but you cannot of course lengthen them). > For some reason the packager decided not to use install_name_tool for that, > and also forgot to take care of the MacPorts dependencies. > I don't know if install_name_tool is always present on user machines or if it > requires the developer tools (which are required anyway for using what the Qt > installer installs...). If one can rely on it, it seems a good idea to use > that tool to adapt the Qt libraries to the user's chosen install location and > handle any remaining MacPorts dependencies at the same time. > That's all the more true if the tool allows something like `install_name_tool > -change /opt/local/lib /usr/lib`, i.e. a path change rather than a path+file > change. > > R. My guess is that the packager does not know about the "-headerpad_max_install_names" linker flag. This tells the linker to pad the "install_names" on the libraries to the max value so that one can change those "install_name" values. There really is NO Need to have some insanely long install path for the package when built. The "-headerpad_max_install_names" needs to be added to the Qt5 build scripts. I'll count that as an Obvious bug and not put in a report. I was also the one that reported the MacPort dependency. And I am not really comfortable just changing the install_name to point towards another library of the same name but unknown as to how it was compiled or with what options. I'll count that as another obvious bug and not put in a bug report. Lastly, CMake has very good support for creating a deployable .app package for OS X, even when using Qt 4/5. The issue with MacDeployQt (it is generally very good) is that our app has its own set of plugins that also need to be adjusted but MacDeployQt does not allow me to send in an additional list of Libraries/Plugins to get adjusted. MacDeployQt actually picked up and properly fixed my .app package including all my third party libraries like HDF5, TBB, Boost, ITK. Now. if QtCreator could just better understand CMake projects I think I could have a decent experience coding with Qt. Cheers Mike Jackson _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
