MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015047CMakeModulespublic2014-07-30 13:302016-06-10 14:31
ReporterJordi Gutiérrez Hermoso 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformMac OS XOSMac OS XOS VersionX.IX
Product VersionCMake 3.0 
Target VersionFixed in Version 
Summary0015047: BundleUtilities' fixup_bundle does not check to see if two libs are the same up to symlinks
DescriptionI'm using cmake's BundleUtilities to create an app bundle. I am using
homebrew's wxmac package to create an application of my own.

With wxmac, my binary links (amongst other things) to

    /usr/local/lib/libwx_baseu-3.0.dylib
    /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib

But /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib itself also links
to libwx_baseu-3.0.dylib, but not to the symlink in /usr/local/lib but
to the original in /usr/local/Cellar which actually has a longer but
compatible version name: libwx_baseu-3.0.0.1.0.dylib (note the extra
dots in the version number). Of course, the 3.0.0.1.0 library is the
same as the 3.0 library, as the latter is jus a symlink to the former.

Thus BundleUtilities thinks that there is a dependency of a dependency
and copies the libwx_baseu library twice, once for 3.0 and again for
3.0.0.1.0 and sets the path twice in my binary.

This creates a segfaulty executable. :-(
Steps To ReproduceIt's a bit complicated to easily reproduce this. Basically, use fixup_bundle, create a library that links both to foo.dylib and bar.dylib, and make sure that bar.dylib is a symlink to baz.dylib and that foo.dylib itself links to baz.

In ASCII art:

    binary
    | \
    | \
    foo bar ..... baz
    | |
    \_________________/

where the dots indicate a filesystem symlink and the solid lines indicate dynamic library linking.
Additional Information(aside: homebrew sets up symlinks in /usr/local/lib that point to the
actual wxmac libraries in /usr/local/Cellar/wxmac/3.0.1, similar to
how most GNU/Linux systems handle /usr/lib and /usr/local/lib )
Tagsmacosx
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-07-30 13:30Jordi Gutiérrez HermosoNew Issue
2014-08-04 22:49Clinton StimpsonNote Added: 0036548
2014-08-04 23:06Clinton StimpsonNote Added: 0036549
2014-08-04 23:21Jordi Gutiérrez HermosoNote Added: 0036550
2014-11-07 11:10niobosNote Added: 0037161
2014-11-07 11:12niobosNote Edited: 0037161bug_revision_view_page.php?bugnote_id=37161#r1612
2014-11-07 11:13niobosTag Attached: macosx
2016-06-10 14:29Kitware RobotNote Added: 0042597
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0036548)
Clinton Stimpson   
2014-08-04 22:49   
I don't think its too much to ask that the homebrew's wx package have consistent install names.
At least from your description, it appears you have inconsistent install names.

Can the homebrew/wx people fix this so that the "id" of the dylib given by:
otool -D /usr/local/lib/libwx_baseu-3.0.dylib
matches the libwx_baseu-3.0.dylib reference in libwx_osx_cocoau_core-3.0.dylib shown by:
otool -L /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib

I do see that the OS X loader supports this, but I'm not aware of the equivalent being done on Unix/Linux where a multiple SONAMEs are used for the same library.
(0036549)
Clinton Stimpson   
2014-08-04 23:06   
Also, I suspect something is wrong in homebrew's wx such that if you get an update
and have both
libwx_baseu-3.0.0.1.0.dylib
and
libwx_baseu-3.0.0.2.0.dylib

and the libwx_baseu-3.0.dylib symlink is changed to point to the newer one, your apps using the older library will now have problems with the update unless you recompile them.

Anyway, I could be off here... which is why its best that you give a concrete example instead of a description.
(0036550)
Jordi Gutiérrez Hermoso   
2014-08-04 23:21   
Sure, homebrew is doing something wrong. That doesn't mean CMake should also do something wrong. It should detect when two files are the same up to symlinks. I tried to fix this myself, but I wasn't able to figure out the code in BundleUtilities.

How does on debug cmake code in general? Is there a debugger, or does one resort to printf debugging?
(0037161)
niobos   
2014-11-07 11:10   
(edited on: 2014-11-07 11:12)
I'm experiencing the same (or a very similar) issue. Example code is here: https://github.com/niobos/cmake-wxwidgets-experiment [^]

The problem indeed seems to be an interaction between the dynamic loader, the way wxmac installs the libraries and how BundleUtilities attempts to "fix" them.

Some information from my bug hunting:

* Before FIXUP_BUNDLE(), the binary works (but uses /usr/local/lib libraries).

* Uninstalling wxWidgets causes the binary to fail loading (dyld: Library not loaded). This is expected.

* After FIXUP_BUNDLE(), the binary segfaults. Note that it does NOT generate linker errors! This is a bug somewhere (either wxmac/homebrew, CMake's BundleUtilities or dyld).


I can "fix" the bundle in multiple ways:

* By replacing libwx_baseu-3.0.dylib with a link to libwx_baseu-3.0.0.2.0.dylib (the way it is in /usr/local/lib)

* By changing the dependency in libwx_osx_cocoau_core-3.0.dylib to point to libwx_baseu-3.0.dylib instead of libwx_baseu-3.0.0.2.0.dylib

* By changing the dependency in hello to point to libwx_baseu-3.0.0.2.0.dylib instead of libwx_baseu-3.0.dylib

* By changing the id (install name) of both libwx_baseu-3.0.dylib and libwx_baseu-3.0.0.2.0.dylib back to /usr/local/lib/libwx_baseu-3.0.dylib (like they were before fixup). Even if this file does not actually exists.
(0042597)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.