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

Michael Jackson mike.jackson at bluequartz.net
Tue May 22 11:35:33 EDT 2012 

You have a bad install of Lion (OS X 10.7.x). I just checked 3 different Lion machines and ALL have OpenCL.framework installed. So I would suspect your Lion Machine. Lion uses OpenCL for lots of system level calls so a Lion Install without OpenCL is just plain Broken.

___________________________________________________________
Mike Jackson                    Principal Software Engineer
BlueQuartz Software                            Dayton, Ohio
mike.jackson at bluequartz.net              www.bluequartz.net

On May 22, 2012, at 11:18 AM, Joe Ping-Lin Hsiao wrote:

> Sorry I forgot to mention what the framework is. I believe the OpenCL
> framework is from MacOS since I checked two Snow Leopard machines and
> both have the framework.
> 
> I am building my program in Snow Leopard. The program uses a library
> called 'ImageMagick', which uses the OpenCL framework. In Snow
> Leopard, I don't have to do anything special to OpenCL. It is just
> like any other system library, and my bundle and installer work fine
> in Snow Leopard.
> 
> The problem is the OpenCL framework is not included in Lion (MacOS
> 10.7). I don't know why Apple changed that. So my program would crash
> if running in Lion.
> My work around was to copy 'libclparser.dylib' into my bundle and
> manually change it's install_name, and also the one used by
> ImageMagick. Luckily it works. Now I am trying to make CMake to do it.
> 
> 
> On Tue, May 22, 2012 at 10:48 AM, David Cole <david.cole at kitware.com> wrote:
>> My previous email was your first hint that this might not be a good idea.
>> 
>> This error message is the second hint that this might not be a good idea.
>> 
>> You can try setting "BU_COPY_FULL_FRAMEWORK_CONTENTS" to ON before calling
>> fixup_bundle. That will recursively copy the framework into the bundle
>> rather than selectively copying just the framework library and its
>> "Resources" folder.
>> 
>> I am very hesitant to recommend copying a "/System" framework into a bundle
>> without knowing more details about where that framework came from.
>> 
>> 
>> On Tue, May 22, 2012 at 10:33 AM, Joe Ping-Lin Hsiao <phsiao at cs.unc.edu>
>> wrote:
>>> 
>>> 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
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 
> --
> 
> 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