[cmake-developers] fixup_bundle with @loader_path
Simon Wells
swel024 at gmail.com
Sat Oct 29 11:25:16 EDT 2016
Hello,
I think i have finally figured out whats causing the issue....
FindBoost.cmake explicitly lists the dependencies for every version,
and therefore provides this information to cmake and getprereqs
function(_Boost_COMPONENT_DEPENDENCIES component _ret)
As each new version of boost is released the dependency information
has to be added manually to FindBoost.cmake.
elseif(NOT Boost_VERSION VERSION_LESS 106200 AND Boost_VERSION
VERSION_LESS 106300) is the newest line which is in trunk but has yet
to be released
As such if one has installed a new boost version and not yet got an
updated cmake version then it will not be providing the right
information as such it seems the getprereqs will then go inspecting
the installed boost libraries
eg.
/usr/local/opt/boost/lib/libboost_context-mt.dylib (compatibility
version 0.0.0, current version 0.0.0)
@loader_path/libboost_chrono-mt.dylib (compatibility version 0.0.0,
current version 0.0.0)
@loader_path/libboost_thread-mt.dylib (compatibility version 0.0.0,
current version 0.0.0)
@loader_path/libboost_system-mt.dylib (compatibility version 0.0.0,
current version 0.0.0)
as such will not understand it and will fail at trying to copy
@loader_path/libboost_chrono-mt.dylib
This explains why the bug has mysteriously disappeared on me a couple
of times and why it never fails to make a reappearance
thanks
Simon
On Fri, Jan 15, 2016 at 7:26 AM, <clinton at elemtech.com> wrote:
>
> ----- On Jan 14, 2016, at 6:48 AM, Brad King brad.king at kitware.com wrote:
>
>> On 01/13/2016 01:38 AM, Simon Wells wrote:
>>> it kept saying that @loader_path/libboost_chrono-mt.dylib was not found
>>
>> It looks like this was now reported here with a patch:
>>
>> https://cmake.org/Bug/view.php?id=15918
>>
>> We already handle @executable_path, so @loader_path should be handled in
>> a similar way but we need to make sure enough information is passed to
>> know the loader path.
>>
>
> As far as I know, the information needed is already available, so my initial guess is that we don't need any significant re-engineering.
>
> Simon,
> Would you happen to have a simple example showing the problem without boost, that would be easy to replicate? That could become the basis for a test.
>
> Clint
More information about the cmake-developers
mailing list