[CMake] fixup_bundle() doesn't like libglut.3.dylib
Joe Ping-Lin Hsiao
phsiao at cs.unc.edu
Tue May 22 15:36:45 EDT 2012
Turns out that ImageMagick is only used by test routines in my
program. I just comment out those routines in CMakeLists.txt and the
main program builds and works fine. I don't have to worry about OpenCL
anymore.
I think this is ImageMagick's fault. If I need this library in the
future, I'll probably need to build the program separately in 10.7 in
order to run it in 10.7.
And thanks David, your posts have been very helpful.
Best,
Joe
On Tue, May 22, 2012 at 12:06 PM, Michael Jackson
<mike.jackson at bluequartz.net> wrote:
> It seems that this library is ONLY installed with Xcode which leads me to believe that libclparser.dylib should ONLY be used during development and is NOT a deployable library. Yes there are all sorts of ideas about copying it from Snow Leopard but there are both technical and legal issues surrounding someone other than Apple distributing that library.
> ___________________________________________________________
> Mike Jackson Principal Software Engineer
> BlueQuartz Software Dayton, Ohio
> mike.jackson at bluequartz.net www.bluequartz.net
>
> On May 22, 2012, at 11:54 AM, Joe Ping-Lin Hsiao wrote:
>
>> 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
>
> --
>
> 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