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

Joe Ping-Lin Hsiao phsiao at cs.unc.edu
Tue May 22 11:54:56 EDT 2012 

My Lion has OpenCL framework too. But if you go down the path, there
is no 'libclparser.dylib' in
/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/,
while it exits in Snow Leopard.

And by googling ImageMagick and libclparser.dylib, I found people
having this issue as well. The solution I see so far is to copy the
.dylib into Lion.

-Joe

On Tue, May 22, 2012 at 11:35 AM, Michael Jackson
<mike.jackson at bluequartz.net> wrote:
> 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
>
> --
>
> 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