[CMake] fixup_bundle() doesn't like libglut.3.dylib

Joe Ping-Lin Hsiao phsiao at cs.unc.edu
Tue May 22 10:33:05 EDT 2012 

After setting the framework type to 'other', the framework structure
is copied into my bundle, including the file OpenCL, but missing
libclparser.dylib.

And I got the following errors:

CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Run preinstall target for: CISMM_VIDEO
CPack: - Install project: CISMM_VIDEO
resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
 // print out by me
resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
                             // print out by me
resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
 // print out by me
resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
 // print out by me
resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
                             // print out by me
  exe_dotapp_dir/='/Users/phsiao/dev/video/video_spot_tracker.app/'
  item_substring='/System/Library/Frameworks/OpenCL.framework/Ver'
  resolved_embedded_item='/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib'

Install or copy the item into the bundle before calling fixup_bundle.
Or maybe there's a typo or incorrect path in one of the args to fixup_bundle?

CMake Error at /Applications/CMake
2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
(message):
  cannot fixup an item that is not in the bundle...
Call Stack (most recent call first):
  /Applications/CMake
2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
(fixup_bundle_item)
  /Users/phsiao/dev/video/video_spot_tracker_install.cmake:17 (fixup_bundle)
  /Users/phsiao/dev/video/cmake_install.cmake:127 (INCLUDE)


CPack Error: Error when generating package: CISMM_VIDEO
make: *** [package] Error 1



On Tue, May 22, 2012 at 6:53 AM, David Cole <david.cole at kitware.com> wrote:
> Yes, it's possible. But I would only advise it if you do it on a
> per-framework basis, you built & installed it yourself, and you know for
> certain that the framework in question works fine when moved from its
> "/System/Library" location.
>
> Is this an OpenCL that you built yourself, or did it come from some package
> manager?
>
> The set of "type" values that GetPrerequisites assigns to files are:
>   set(type "system")
>   set(type "embedded")
>   set(type "local")
>   set(type "other")
>
> "system" means never copy, never fixup
> "embedded" means it will be inside the app bundle, and may be addressed
> relative to @executable_path after fixup_bundle is done
> "local" means it is in exactly the same directory as the executable
> "other" is everything else
>
> So, in your case, you'd want to match on the file path beginning and set the
> type to "other". Just add another chunk inside your override function that
> looks like this:
>
>      if(resolved_file MATCHES
> "^/System/Library/Frameworks/OpenCL.framework")
>        message("resolving ${resolved_file} as other")
>        set(${type_var} other PARENT_SCOPE)
>      endif()
>
>
> HTH,
> David
>
>
> On Mon, May 21, 2012 at 4:01 PM, Joe Ping-Lin Hsiao <phsiao at cs.unc.edu>
> wrote:
>>
>> Thanks, David. It works!
>>
>> Is it possible to do the other way around?
>> I want fixup_bundle() to treat
>>
>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>> as an external library instead of a system lib. I looked at functions
>> in BundleUtilities.cmake and GetPrerequisites.cmake but didn't get any
>> clue how to do that.
>>
>> Thanks,
>> Joe
>>
>> On Mon, May 14, 2012 at 8:47 PM, David Cole <david.cole at kitware.com>
>> wrote:
>> > Rather than just doing a "fixup_bundle" as an INSTALL(CODE snippet, put
>> > it
>> > in a separate CMake script, and use install(SCRIPT to execute it. You
>> > can
>> > configure the script with configure_file if you need to put stuff in it
>> > that
>> > depends on CMake variables.
>> >
>> > Then, in your script:
>> >
>> >   # Define the function before including BundleUtilities:
>> >   function(gp_resolved_file_type_override resolved_file type_var)
>> >     if(resolved_file MATCHES "^/usr/X11/lib")
>> >       message("resolving ${resolved_file} as system")
>> >       set(${type_var} system PARENT_SCOPE)
>> >     endif()
>> >   endfunction()
>> >
>> >   include(BundleUtilities)
>> >
>> >   fixup_bundle( ... )
>> >
>> > ParaView's install rules on the Mac do something like this, if you want
>> > to
>> > look at some example code.
>> >
>> >
>> > HTH,
>> > David
>> >
>> >
>> > On Mon, May 14, 2012 at 5:27 PM, Joe Ping-Lin Hsiao <phsiao at cs.unc.edu>
>> > wrote:
>> >>
>> >> Thanks, this is exactly what I need.
>> >>
>> >> Just one question.  Why the function gp_resolved_file_type_override()
>> >> cannot be seen if it is implemented in my project's CMakeLists.txt? I
>> >> have to add it in GetPrerequisite.cmake module, but that's not good.
>> >>
>> >> Thanks,
>> >> Joe
>> >>
>> >> On Mon, May 7, 2012 at 11:04 AM, David Cole <david.cole at kitware.com>
>> >> wrote:
>> >> > /usr/X11/lib/libglut.dylib should probably be considered a "system
>> >> > library" that is not included in your final bundle.
>> >> >
>> >> > Therefore, all users of your application will have to have the Mac OS
>> >> > X version of X installed and available in order to run your program.
>> >> > (Is that all Macs nowadays anyway...?)
>> >> >
>> >> > In order to classify it as a system library, you can provide a CMake
>> >> > function named gp_resolved_file_type_override to look for that
>> >> > library
>> >> > (probably anything starting with "/usr/X11/lib") and set its type to
>> >> > "system" -- that will cause fixup_bundle to ignore it for copying and
>> >> > fixup purposes.
>> >> >
>> >> >
>> >> > HTH,
>> >> > David
>> >> >
>> >> >
>> >> > On Mon, May 7, 2012 at 10:57 AM, Joe Ping-Lin Hsiao
>> >> > <phsiao at cs.unc.edu>
>> >> > wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I use CMake to create an installer for a Mac program which uses
>> >> >> GLUT.
>> >> >> The GLUT library that the program links against with is
>> >> >> /usr/X11/lib/libglut.dylib.
>> >> >>
>> >> >> When I use fixup_bundle() to create an installer, I get the
>> >> >> following
>> >> >> error message:
>> >> >>
>> >> >> install_name_tool: changing install names or rpaths can't be redone
>> >> >> for:
>> >> >>
>> >> >> /Users/phsiao/dev/video/video_spot_tracker.app/Contents/MacOS/libglut.3.dylib
>> >> >> (for architecture ppc7400) because larger updated load commands do
>> >> >> not
>> >> >> fit (the program must be relinked, and you may need to use
>> >> >> -headerpad
>> >> >> or -headerpad_max_install_names)
>> >> >>
>> >> >> The first thing I tried was to add -headerpad_max_install_names and
>> >> >> -headerpad to the linker flags, but no success. (Actually
>> >> >> -headerpad_max_install_names already exists in CMakeFies/link.txt
>> >> >> before I put it in.)
>> >> >>
>> >> >> The next thing I tried was to add '-arch x86_64' to both CXX_FLAGS
>> >> >> and
>> >> >> LINKER_FLAGS to avoid fixup_bundle() to fix dependencies for
>> >> >> architecture ppc7400, but the error remains.
>> >> >>
>> >> >> Any idea how to get around this?
>> >> >>
>> >> >> Thanks,
>> >> >> Joe
>> >> >> --
>> >> >>
>> >> >> Powered by 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
>> >
>> >
>
>

More information about the CMake mailing list