[CMake] Problems with BundleUtilities and wxWidgets on OSX

Bernhard Stegmaier stegmaier at sw-systems.de
Sun May 25 13:17:58 EDT 2014


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





More information about the CMake mailing list