Mac CMake build needs to set INSTALL_NAME_DIR on libinkscape_base

Bug #1781701 reported by RJVB
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Invalid
Undecided
Unassigned

Bug Description

The CMake build system needs to set the INSTALL_NAME_DIR property on libinkscape_base.dylib on Mac.

Failing to do so causes the build to assume that the library is installed in $prefix/lib rather than in $prefix/lib/inkscape and as a result inkscape will fail to load. The property is only used on Mac so it can be set unconditionally as in the attached patch. (And yes, it beats me too why CMake doesn't do this automatically based on the library's target install location.)

Observed in Inkscape 0.92.3 and INKSCAPE_0_92_3-21-gcdafc07 (current head of the 0.92.x branch).

Revision history for this message
RJVB (rjvbertin) wrote :
Revision history for this message
Patrick Storz (ede123) wrote :

Hi RJVB,

thank you very much for working on the Mac build! We really need some capable hands helping out with it!

I had a look at your patch and while it probably works around the issue I think it's not the correct solution as RPATH should be in use on Mac, see [1]. This *should* allow the executable to locate the shared lib in "CMAKE_INSTALL_RPATH" which is set to "@loader_path/../lib/inkscape". In this case INSTALL_NAME_DIR should not be used, as it effectively disables RPATH again, see [2].

Could you double check if any other paths are set wrongly? Maybe also [3] can help. Unfortunately I'm not on Mac (an neither is any of the other active developers) so I can only guess...

P.S. Did you know Inkscape code is hosted on GitLab [4]? If you want you can create merge requests over there which will make code review even easier and might give your patches more visibility.

[1] https://gitlab.com/inkscape/inkscape/blob/b190394114fb32c0636aa8deb94bf2108616a4d4/CMakeLists.txt#L43-45
[2] https://blog.kitware.com/upcoming-in-cmake-2-8-12-osx-rpath-support/
[3] https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling
[4] https://gitlab.com/inkscape/inkscape

Revision history for this message
RJVB (rjvbertin) wrote :

I had not seen the RPATH code for APPLE in the CMake file, and my build scripts set those explicitly which probably explains part of the issue I'm seeing.

I've redone the build without those explicit settings, and still see the same issue when I use the Mac's `ldd` equivalent (but I haven't yet tried to run the binary). Cmake appears to separate the rpath information stored in the application, and the paths it hardcodes in binaries (including dylib "IDs" which are stored in dependents by the link editor). In order to make things consistent you'll probably have to use INSTALL_NAME_DIR to set the libinkscape_base ID to @loader_path/../lib ...

Something else: you'll probably want to append or prepend to CMAKE_INSTALL_RPATH instead of resetting it, i.e. `set(CMAKE_INSTALL_RPATH "<newval>;${CMAKE_INSTALL_RPATH}")`

I also wasn't aware that the source is (also) hosted on gitlab, only of the mirror/fork here on LP.

Revision history for this message
RJVB (rjvbertin) wrote :

Anyway, I couldn't get the stock version to work.

- with `CMAKE_BUILD_WITH_INSTALL_NAME_DIR` set (the usual default on Mac), libinkscape_base will have a full path in its ID, set to $prefix/lib/libinkscape_base.dylib (= not the correct path). This will override the rpath info in the executable (as it should; rpath is only used when no absolute/full information is available).
- with that variable not set (or set to false), libinkscape_base will have ID `@rpath/inkscape/libinkscape_base.dylib`, i.e. $prefix/lib replaced by @rpath. For some reason this also doesn't work properly; not sure I understand why.

I've updated my patch so it should be most robust regardless of what commandline arguments the user adds.

Revision history for this message
Qantas94Heavy (qantas94heavy) wrote :

Assuming fixed with 1.0 branch, please post new bug on https://inkscape.org/report if not the case.

Closed by: https://gitlab.com/Qantas94Heavy

Changed in inkscape:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.