[CMake] still having rpath problems on osx

Boudewijn Rempt boud at valdyas.org
Thu Dec 24 02:24:03 EST 2015


On Wed, 23 Dec 2015, Michael Jackson wrote:

>>
>> Hm... Okay -- so, since I all my dependencies myself as cmake external projects, I guess I want all of them set to rpath. I guess that for boost, with its own build system, I'll need to add a separate fix-up step to my cmake externals project for boost. I have to check how I can fix the dependencies that are still automake/autoconf based. And I'll try what you suggest below for my own project.
>
> I have written scripts to do things like that for boost and ITK where the libraries do not have anything like @rpath or the absolute path to the installed library. After installing I run those scripts to “fix” the libraries so when I debug I can just run the application. During packaging I then run CMake’s BundleUtilities to copy in the libraries and adjust the libraries to have @rpath or @executable_path.
>
> When fixing up a library make sure you also fix all the dependent libraries that might be there. For things like Boost or ITK their higher level libraries depend on their lower level libraries. Using “otool -L” you can see this. Make sure you update EVERY path in the library.
>
> Also using MacDeployQt will NOT fix up any NON-Qt libraries (like Boost, HDF5.. ) so you will still need to run/write something that fixes all of those libraries. For our project we wrote a pure CMake script that does everything we need to fix up our bundles so that everything is self contained.

Hm... And it all did work when my project was still Qt4-based and I built on Mavericks... And I've got about 300 libraries in the project, including plugins. Resetting the id of broken libraries and then rebuilding my project works. Are your scripts public so I can take a look and maybe reuse them?

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org


More information about the CMake mailing list