Opened 17 years ago

Closed 15 years ago

#768 closed defect (fixed)

A few lib paths wrong in OSX

Reported by: kyngchaos Owned by: nobody
Priority: major: does not work as expected Milestone: Version 1.0.3
Component: Build/Install Version: Trunk
Keywords: Cc: telwertowski@…
Must Fix for Release: Yes Platform: OS X
Platform Version: Awaiting user input: no

Description

msexport, qgis_help and the qgis python libs (core.so and gui.so) link to the source copies of libqgis_core and libqgis_gui. Probably an install_name_tool step missed?

The python qgis libs' linking is a bit tricky, and @executable_path is probably not a good method to use. It would have to be relative to the python executable in /Library/Frameworks which is outside the Qgis bundle, which would make Qgis.app non-relocatable. @loader_path would be better (ie @loader_path/../../../../lib/libqgis_core.dylib) - it's relative to the library or program loading the library referenced. BUT, this is a Tiger-only feature, so this would make Python Qgis features Tiger+ -only.

AND, the Qgis plugins would then also have to use @loader_path. Thus making all of Qgis Tiger+ -only. For a basic Qgis build, with all Qt frameworks and PyQt/SIP outside the Qgis bundle, here's what I came up with:

  • bin
    • msexport.app/Contents/MacOS/msexport
      • qgis_core -> @executable_path/../../../../lib/
      • qgis_gui -> @executable_path/../../../../lib/
    • qgis_help.app/Contents/MacOS/qgis_help
      • qgis_core -> @executable_path/../../../../lib/
  • lib
    • libqgis_gui
      • qgis_core -> @loader_path/
    • libqgisgrass
      • qgis_core -> @loader_path/
    • qgis [plugins]
      • all
        • qgis_core -> @loader_path/../
        • qgis_gui -> @loader_path/../
  • qgis [app]
    • qgis_core -> @executable_path/lib/
    • qgis_gui -> @executable_path/lib/
  • share/qgis/python/qgis
    • core, gui
      • qgis_core, qgis_gui -> @loader_path/../../../../lib/

Executables (qgis, msexport, qgis_help) should use @executable_path. Libraries should use @loader_path.

Change History (14)

comment:1 by pcavallini, 16 years ago

has this been fixed? please check and close it if appropriate

comment:2 by jctull, 16 years ago

This has not been fixed.

comment:3 by kyngchaos, 16 years ago

Milestone: Version 0.9.2Version 0.10.0
Must Fix for Release: NoYes

As reported recently on the mailing list, this seems to be affecting the operation of some (all?) python plugins.

Other info - it looks like the @loader_path method is not required. Fixing the python core.so and gui.so to use @executable_path (as the rest of Qgis currently uses) works.

comment:4 by jctull, 16 years ago

Here is the workaround for the python plugin failure from the dev list. This manual fix can be applied by those who are looking for a short-term fix. This workaround was provided by William (kyngchaos), and it may help whoever works on the code:

The paths all depend on where you have your source and where you install Qgis, so I won't give explicit paths here. After installing, open the qgis app package (right-click, Show Package Contents). Dig into Contents/MacOS/share/qgis/python/qgis to find core.so and gui.so. (I do this to easily get the path so I don't have to type it in the Terminal)

In a Terminal, type

otool -L

(that's a space after the L) and drag gui.so to the Terminal window. Press return.

Towards the top should be a line for libqgis_gui.0.11.dylib and a line for libqgis_core.0.11.dylib. Type:

sudo install_name_tool -change path/to/libqgis_gui.dylib @executable_path/lib/libqgis_gui.dylib -change path/to/libqgis_core.dylib @executable_path/lib/libqgis_core.dylib [drag gui.so to Terminal]

for the /path/to/libqgis_*.dylib above, copy and paste what you found for the full path to each library in otool -L.

For example *this is just for mine* :

sudo install_name_tool -change /Users/Shared/src/qgis/svn/qgis_r8652/build-leo/src/gui/libqgis_gui.0.11.dylib @executable_path/lib/libqgis_gui.dylib -change /Users/Shared/src/qgis/svn/qgis_r8652/build-leo/src/core/libqgis_core.0.11.dylib @executable_path/lib/libqgis_core.dylib /Applications/qgis0.11.0.app/Contents/MacOS/share/qgis/python/qgis/gui.so

Do the same for core.so. You can just up-arrow to get the previous command and change gui.so to core.so at the very end of the command. It doesn't matter that core.so doesn't have libqgis_gui.dylib in it, it will ignore that.

Run otool -L on them again to verify the change.

comment:5 by timlinux, 15 years ago

Tom / William can you offer a permanent fix for this or can we otherwise close this somehow.

Regards

Tim

comment:6 by kyngchaos, 15 years ago

I tried to make sense of the cmake setup. The progress output is no help, even with verbose.

It looks like src/helpviewer/cmake_install.cmake is where the install_name_tool step happens for help_viewer, and it looks right. So maybe it's skipping the install_name_tool step for some reason?

It looks like python/cmake_install.cmake is where the python qgis modules are installed, but I see no install_name_tool steps there.

comment:7 by kyngchaos, 15 years ago

... And the cmake_install.cmake's are generated from cmakelists, of course...

for the python modules, which are missing the instal_name_tool... as an example, the main qgis gui library, it has:

INSTALL(TARGETS qgis_gui
  RUNTIME DESTINATION ${QGIS_BIN_DIR}
  LIBRARY DESTINATION ${QGIS_LIB_DIR}
  ARCHIVE DESTINATION ${QGIS_LIB_DIR})

I'm guessing that the cmake INSTALL LIBRARY and RUNTIME keywords tell cmake to generate the install_name_tool steps on OSX. The python cmakelists.txt only uses the FILES keyword:

INSTALL(FILES __init__.py ${CMAKE_CURRENT_BINARY_DIR}/qgisconfig.py ${BINDINGS_LIBS} DESTINATION ${SITE_PKG_PATH}/qgis)

comment:8 by pcav, 15 years ago

Has this been fixed in 1.0? If so, please close it.

comment:9 by kyngchaos, 15 years ago

Cc: telwertowski@… added

qgis_help is OK now.

But the Qgis Python libs are still a problem.

No word from Tom - I wonder if he's seen this? I added him to the CC for the ticket just in case.

comment:10 by kyngchaos, 15 years ago

Correction - help_viewer now has a different linkng problem. it links @executable_path/lib/libqgis_core.1.0.dylib, and since it's not in MacOS folder, but in MacOS/bin/qgis_help.app..., it doesn't work.

The relative path here should be @executable_path/../../../../lib/libqgis_core.1.0.dylib.

comment:11 by kyngchaos, 15 years ago

I have no idea how to fix this in the cmake files. But now that there is the Xcode (in trunk only) project that's working out well, the cmake build is not critical to me. For 1.0.x releases I can post-process the build.

If someone can figure this out, great.

comment:12 by kyngchaos, 15 years ago

Ah, see part of patch submitted in #1658.

comment:13 by kyngchaos, 15 years ago

As I noted in #1658, the install_name_tool step should be done at install like the rest of Qgis, so it can't happen in the python compilation.

comment:14 by kyngchaos, 15 years ago

Resolution: fixed
Status: newclosed

Ooh. The key is the BUILD_WITH_INSTALL_RPATH cmake target property. That was easy. This setting shouldn't be a problem with an OSX build because the application is not executable in the source until assembled in the application package.

Fixed in trunk r11550 and 1.0 r11551

Note: See TracTickets for help on using tickets.