Hi list,
I tried to create a portable application bundle for an application using
wxWidgets with BundleUtilities (fixup_bundle).
It basically works, but I have two problems… any hints would be very helpful.
*** Problem 1: dylib symlinks
The application is built against shared wxWidgets libraries installed via
MacPorts.
This is what wxWidgets creates as libraries:
<<<
-rwxr-xr-x 1 root staff 5435032 20 Nov 2013
libwx_osx_cocoau_core-3.0.0.0.0.dylib
lrwxr-xr-x 1 root staff 37 24 Mai 21:06
libwx_osx_cocoau_core-3.0.0.dylib -> libwx_osx_cocoau_core-3.0.0.0.0.dylib
lrwxr-xr-x 1 root staff 33 24 Mai 21:06
libwx_osx_cocoau_core-3.0.dylib -> libwx_osx_cocoau_core-3.0.0.dy
>>>
One “real” lib and a couple of symlinks with less detailed version numbers
pointing to each other.
At least quite common in the Linux world…
The (cmake-built) application binaries now link against
libwx_osx_cocoau_core-3.0.dylib
whereas another used library of wxWidgets itself (e.g.,
libwx_osx_cocoau_gl.3.0.dylib) links against
libwx_osx_cocoau_core-3.0.0.0.0.dylib
fixup_bundle now ends up copying each version to the app bundle, a …-3.0.dylib
and a …-3.0.0.0.0.dylib.
Unfortunately, it is not symlinking one to the other but copies them as
identical instances.
So, executing the application binary fails because it loads separate instances
of the dylib.
If I manually turn one of the copied links into a symlink to the other,
everything works fine.
I googled around quite a bit, but I didn’t find any hints… since symlinking
library versions is quite common AFAIK, what am I missing and/or is there a fix
for this?
BTW: I also tried dylibbundler, which seems to have the same problem...
*** Problem 2: Framework handling
MacPorts installs wxWidgets dylibs to the path
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/…
The application is linked normally against a library in that path.
Because of the “.framework" folder BindUtilities think that this is about a
framework, but then the regular expression
string(REGEX REPLACE "^.*(${item_name}.framework/.*/?${item_name}).*$”
doesn’t match (because item_name is sth. like "libwx_osx_…dylib" instead of
“wxWidgets") and the resulting embedded_name is just the full path/name of the
library - and then it isn’t copied to the bundle later on.
I temporarily commented out the framework stuff and then it copies the library
without any problem just like any other dylib.
Should the framework detection be extended such that it doesn’t think of a
framework if a single library (ending with .dylib) contains .framework? Or, is
the folder naming as done by MacPorts installation just wrong/illegal?
Best regards,
Bernhard
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
