[CMake] Question about BundleUtilities
David Cole
david.cole at kitware.com
Fri Oct 22 11:30:06 EDT 2010
On Fri, Oct 22, 2010 at 11:22 AM, Marco Nolden
<m.nolden at dkfz-heidelberg.de>wrote:
> On 10/19/2010 11:26 PM, David Cole wrote:
>
>> How does "..../install/MacOS/liblibB.dylib" end up in the list of
>> references that libA depends on if that's not where libB is built....?
>>
>>
> Asking the right questions sometimes helps, thank you ;) This particular
> error was caused by a lib lying around in the build tree from a previous
> build ...
>
> Finally we solved a lot of problems with the overrides. One thing that is
> maybe a bug: in copy_resolved_item_into_bundle the RPATH gets removed on
> linux even if resolved_item == resolved_embedded_item . This caused problems
> for us if fixing two executables with two different fixup_bundle calls in
> one project. We used an override to type "system" to prevent this, but it
> does not seem to be logical.
>
> Everything works now for Linux and Mac OS after a "make install" , which is
> really great (Windows testing has just started). But when using CPack it
> does not include the automatic copied libraries. I read about this issue in
> the cmake-users archives, but there was no real solution. Are there any news
> about that feature?
>
What is the exact problem here? Mac or Linux? You said it works after "make
install" but then the copied libs do not end up in the CPack package? (By
default, CPack just does a make install to construct its install tree for
packaging. Are you overriding it somehow?)
>
> BTW, the BundleUtilities are a great tool, I think you should advertise it
> more, also for Linux and Windows.
>
Thanks! It's really great that so many people have taken it up and started
using it. Especially thanks to Clinton Stimpson for all of his effort to
make it work well everywhere, not just on the Mac.
Where/how would you suggest we advertise it more? We pretty much count on
word-of-mouth of satisfied folks like you to spread the word for us...!
Thanks,
David Cole
>
> Best,
>
> Marco
>
>
>
>
>> On Tue, Oct 19, 2010 at 5:14 PM, Marco Nolden
>> <m.nolden at dkfz-heidelberg.de <mailto:m.nolden at dkfz-heidelberg.de>> wrote:
>>
>> On 10/19/2010 05:47 PM, David Cole wrote:
>>
>>> This likely means that "otool -L" on libA is reporting
>>> "/Users/engelm/bundle-test/install/MacOS/liblibB.dylib" as a
>>> dependent library... If that's true, then why doesn't the library
>>> exist?
>>>
>> It exists in the build tree but we did not add install commands for
>> it, because we thought it would be done by the BundleUtilities
>> script (and in fact on linux libB does get copied to the install
>> tree automatically).
>>
>> So is this "automatic copying" of libraries intended for libraries
>> in the same project as well or is it only intended for 3rd party
>> libraries from other directories?
>>
>>
>>
>>> Do you build libA against a build tree including libB or against
>>> an install tree of libB...?
>>>
>>> Both libraries are built within the same project.
>>
>>
>> Yes, that is basically the intended usage of BundleUtilities. It
>>> looks like you are using it correctly. Errors are difficult to
>>> diagnose, though.....
>>>
>>>
>>> I know, we already spent some time trying to get it to work ;) Is
>> the test project useful? Can we help in some other way?
>>
>> Best
>> Marco
>>
>>
>> HTH,
>>> David
>>>
>>>
>>> On Tue, Oct 19, 2010 at 10:34 AM, Marco Nolden
>>> <m.nolden at dkfz-heidelberg.de <mailto:m.nolden at dkfz-heidelberg.de>>
>>>
>>> wrote:
>>>
>>> Dear all,
>>>
>>> we have some problems using the BundleUtilities macro for
>>> deployment on Mac OS X. I created a very small test project
>>> which is similar to our setup:
>>>
>>> http://github.com/nolden/bundle-test
>>>
>>> - libA is a plugin that would be loaded at runtime by means of
>>> dlopen (or something similar). We added an explicit
>>> INSTALL(TARGETS libA) for this library.
>>>
>>> - libB is a dependency of libA
>>>
>>> - Main is an indepedent main application that would in
>>> practice load libA with dlopen (not in the example)
>>>
>>> Calling fixup_bundle with libA as a plugin gives some errors
>>> on Mac OS, because libB is not copied to the install tree:
>>>
>>> Install the project...
>>> -- Install configuration: ""
>>> -- Installing: /Users/engelm/bundle-test/install/lib/liblibA.dylib
>>> -- Installing: /Users/engelm/bundle-test/install/bin/Main
>>> GetPreReq
>>> -- fixup_bundle
>>> -- app='/Users/engelm/bundle-test/install/bin/Main'
>>> -- libs='/Users/engelm/bundle-test/install/lib/liblibA.dylib'
>>> -- dirs='/Users/engelm/bundle-test/bin/bin'
>>> -- fixup_bundle: preparing...
>>> -- warning: embedded item does not exist
>>> '/Users/engelm/bundle-test/install/MacOS/liblibB.dylib'
>>> --
>>>
>>> ******************************************************************************
>>> warning: cannot resolve item
>>> '@executable_path/../MacOS/liblibB.dylib'
>>>
>>> On Linux, the copying of the dependencies works, we have not
>>> tested windows yet.
>>>
>>> Is this the intended use of the BundleUtilities script? It
>>> looks like a very good solution for cross-platform deployment.
>>>
>>> Best,
>>>
>>> Marco / Sascha
>>>
>>> MITK, http://www.mitk.org
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com <http://www.kitware.com>
>>>
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/listinfo/cmake
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101022/ac96467e/attachment.htm>
More information about the CMake
mailing list