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 probab
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 surro
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 solu
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.
__
I have Lion 10.7.4 on my laptop and I do have an OpenCL.framework in
"/System/Library/Frameworks/OpenCL.framework/"
So the real question is: why doesn't it just work for you? Because it
should work without you having to copy the OpenCL framework into your
bundle.
Especially if the OpenCL.framewor
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
L
If you compile/install these 3rd party libraries yourself, and compile against
them, then they are automatically recognized as non-system libraries. That's
the approach I take instead of trying to overload the behavior to treat some
system libraries as non-system ones.
Clint
On Tuesday, May
I too am curios as to why you need to copy ANYTHING from /System/Frameworks.
Typically if a framework is in there then it is installed on OS X BY Apple. If
you are deploying your application to an OS X machine that does NOT have this
file then the version of the operating system (OS X) will NOT
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
rat
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
CP
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
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.
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 functi
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
/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...?)
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 c
16 matches
Mail list logo
