Discussion:
[CMake] SDL troubles on Mac OS X
Werner Smekal
2009-12-15 07:51:45 UTC
Permalink
Hi,

I'm building an application on Mac OS X and link the SDL libraries into
the app. Basically it all works fine (app runs, etc.), but if I want to
use the BundleUtilities to fix/include the SDL framework into the app
bundle I encounter errors. Problem is, that the references to the SDL
libraries in the executable already point to
"@executable_path/../Frameworks/...." although the SDL Frameworks are
not there (see below). BundleUtilities is then not able to find the SDL
Frameworks. In my opinion the references should point to
~/Library/Frameworks. I wonder why this app runs, but maybe Mac OS X
looks for other standard locations if it doesn't find the library. I
googled around but could only find one other post:

http://avidemux.org/admForum/viewtopic.php?id=5802

where it is mentioned that: "However, cmake "thinks" that the
SDL.framework is already inside the bundle (and therefore doesn't copy
it), but cmake can't find it in the next step."

Is this a cmake bug, a FindSDL.cmake bug or is it just me :)

Thanks for any help,
Werner


More information. Here is what I do:

1) Download the SDL and SDL-Mixer Frameworks and copy them to
~/Library/Frameworks

2) Try to find them with

find_package(SDL REQUIRED)
include_directories(${SDL_INCLUDE_DIR})

find_package(SDL_mixer REQUIRED)
include_directories(${SDLMIXER_INCLUDE_DIR})

which also works ok:

SDL_INCLUDE_DIR = /Users/smekal/Library/Frameworks/SDL.framework/Headers
SDL_LIBRARY =
/Users/smekal/Library/Frameworks/SDL.framework;-framework Cocoa
SDLMIXER_INCLUDE_DIR =
/Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers
SDLMIXER_LIBRARY = /Users/smekal/Library/Frameworks/SDL_mixer.framework

3) Link them to my target:

target_link_libraries(
zct
${SDL_LIBRARY}
${SDLMIXER_LIBRARY}
${OPENGL_LIBRARIES}
)

4) Verbose compile (example):

[ 7%] Building CXX object CMakeFiles/zct.dir/src/game/app.cpp.o
/usr/bin/c++ -mmacosx-version-min=10.5
-I/Users/smekal/Library/Frameworks/SDL.framework/Headers
-I/Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers -Wall
-F/Users/smekal/Library/Frameworks -o
CMakeFiles/zct.dir/src/game/app.cpp.o -c
/Users/smekal/Development/zct/src/game/app.cpp
"/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake" -E
cmake_progress_report /Users/smekal/Development/zct/build/CMakeFiles 2

5) Verbose Link:

Linking CXX executable zct.app/Contents/MacOS/zct
"/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake" -E
cmake_link_script CMakeFiles/zct.dir/link.txt --verbose=1
/usr/bin/c++ -mmacosx-version-min=10.5 -Wl,-search_paths_first
-headerpad_max_install_names CMakeFiles/zct.dir/src/game/app.cpp.o
CMakeFiles/zct.dir/src/game/being.cpp.o
CMakeFiles/zct.dir/src/game/controller.cpp.o
CMakeFiles/zct.dir/src/game/display.cpp.o
CMakeFiles/zct.dir/src/game/main.cpp.o
CMakeFiles/zct.dir/src/game/map.cpp.o
CMakeFiles/zct.dir/src/game/organizer.cpp.o
CMakeFiles/zct.dir/src/game/error.cpp.o
CMakeFiles/zct.dir/src/game/location.cpp.o
CMakeFiles/zct.dir/src/game/pathnode.cpp.o
CMakeFiles/zct.dir/src/game/point.cpp.o
CMakeFiles/zct.dir/src/game/tile.cpp.o
CMakeFiles/zct.dir/src/game/SDLMain.m.o -o zct.app/Contents/MacOS/zct
-F/Users/smekal/Library/Frameworks -framework SDL -framework Cocoa
-framework SDL_mixer -framework AGL -framework OpenGL

6) and if I look at the references with otool:

pico:build smekal$ otool -L zct.app/Contents/MacOS/zct
zct.app/Contents/MacOS/zct:
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 12.0.0)

@executable_path/../Frameworks/SDL_mixer.framework/Versions/A/SDL_mixer
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 111.1.4)

/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility
version 1.0.0, current version 32.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 227.0.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 476.19.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(compatibility version 45.0.0, current version 949.54.0)

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
(compatibility version 1.0.0, current version 34.0.0)

/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 677.26.0)
Michael Wild
2009-12-15 08:58:16 UTC
Permalink
Hi

What is the install-name of SDL.framewor/SDL? What does

otool -L ~/Library/Frameworks/SDL.framework/SDL

tell you? I suspect it is something like

/Users/smekal/Library/Frameworks/SDL.framework/SDL:
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL (compatibility version 1.0.0, current version 1.0.0)
....

right? The second line is the one the linker uses to embed as a reference into your executable. The linker doesn't use it's actual location, but the library's install name.

Not sure what's going wrong in the CMake part, though...

IMHO FindSDL.cmake is buggy. The variable SDL_LIBRARY (and all its siblings) should only contain the framework, not Cocoa. Another variable, SDL_LIBRARIES (which should be uncached) should then contain the value of SDL_LIBRARY and all other required supporting libraries, such as Cocoa on OS X.

For now, what you can do is manually install the SDL framework using install(DIRECTORY ...) and the first list element of SDL_LIBRARY.

HTH

Michael
Post by Werner Smekal
Hi,
http://avidemux.org/admForum/viewtopic.php?id=5802
where it is mentioned that: "However, cmake "thinks" that the SDL.framework is already inside the bundle (and therefore doesn't copy it), but cmake can't find it in the next step."
Is this a cmake bug, a FindSDL.cmake bug or is it just me :)
Thanks for any help,
Werner
1) Download the SDL and SDL-Mixer Frameworks and copy them to ~/Library/Frameworks
2) Try to find them with
find_package(SDL REQUIRED)
include_directories(${SDL_INCLUDE_DIR})
find_package(SDL_mixer REQUIRED)
include_directories(${SDLMIXER_INCLUDE_DIR})
SDL_INCLUDE_DIR = /Users/smekal/Library/Frameworks/SDL.framework/Headers
SDL_LIBRARY = /Users/smekal/Library/Frameworks/SDL.framework;-framework Cocoa
SDLMIXER_INCLUDE_DIR = /Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers
SDLMIXER_LIBRARY = /Users/smekal/Library/Frameworks/SDL_mixer.framework
target_link_libraries(
zct
${SDL_LIBRARY}
${SDLMIXER_LIBRARY}
${OPENGL_LIBRARIES}
)
[ 7%] Building CXX object CMakeFiles/zct.dir/src/game/app.cpp.o
/usr/bin/c++ -mmacosx-version-min=10.5 -I/Users/smekal/Library/Frameworks/SDL.framework/Headers -I/Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers -Wall -F/Users/smekal/Library/Frameworks -o CMakeFiles/zct.dir/src/game/app.cpp.o -c /Users/smekal/Development/zct/src/game/app.cpp
"/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake" -E cmake_progress_report /Users/smekal/Development/zct/build/CMakeFiles 2
Linking CXX executable zct.app/Contents/MacOS/zct
"/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/zct.dir/link.txt --verbose=1
/usr/bin/c++ -mmacosx-version-min=10.5 -Wl,-search_paths_first -headerpad_max_install_names CMakeFiles/zct.dir/src/game/app.cpp.o CMakeFiles/zct.dir/src/game/being.cpp.o CMakeFiles/zct.dir/src/game/controller.cpp.o CMakeFiles/zct.dir/src/game/display.cpp.o CMakeFiles/zct.dir/src/game/main.cpp.o CMakeFiles/zct.dir/src/game/map.cpp.o CMakeFiles/zct.dir/src/game/organizer.cpp.o CMakeFiles/zct.dir/src/game/error.cpp.o CMakeFiles/zct.dir/src/game/location.cpp.o CMakeFiles/zct.dir/src/game/pathnode.cpp.o CMakeFiles/zct.dir/src/game/point.cpp.o CMakeFiles/zct.dir/src/game/tile.cpp.o CMakeFiles/zct.dir/src/game/SDLMain.m.o -o zct.app/Contents/MacOS/zct -F/Users/smekal/Library/Frameworks -framework SDL -framework Cocoa -framework SDL_mixer -framework AGL -framework OpenGL
pico:build smekal$ otool -L zct.app/Contents/MacOS/zct
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
@executable_path/../Frameworks/SDL_mixer.framework/Versions/A/SDL_mixer (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 32.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.19.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.54.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.26.0)
_______________________________________________
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
http://www.cmake.org/mailman/listinfo/cmake
Werner Smekal
2009-12-15 09:31:40 UTC
Permalink
Hi Michael,
Post by Michael Wild
Hi
What is the install-name of SDL.framewor/SDL? What does
otool -L ~/Library/Frameworks/SDL.framework/SDL
tell you? I suspect it is something like
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL (compatibility version 1.0.0, current version 1.0.0)
....
right? The second line is the one the linker uses to embed as a reference into your executable. The linker doesn't use it's actual location, but the library's install name.
Yes that's right. It was actually 5 minutes after I wrote my email, that
I remembered somewhere back in my head, that the library itself has this
reference, so this explains, why the executable also has this reference.
Post by Michael Wild
Not sure what's going wrong in the CMake part, though...
I assume BundleUtilties uses this reference to copy the libraries into
the app - if the library itself has a "wrong" reference it's not able to
find the library, or?
Post by Michael Wild
IMHO FindSDL.cmake is buggy. The variable SDL_LIBRARY (and all its siblings) should only contain the framework, not Cocoa. Another variable, SDL_LIBRARIES (which should be uncached) should then contain the value of SDL_LIBRARY and all other required supporting libraries, such as Cocoa on OS X.
For now, what you can do is manually install the SDL framework using install(DIRECTORY ...) and the first list element of SDL_LIBRARY.
Thanks, that is what I'm doing right now and this works perfectly. Also
the default XCode project provided by the SDL people does the same -
copying the framework directly into the bundle (without otooling and
install_name_tooling around).
Post by Michael Wild
HTH
Definitely!

Thanks,
Werner
Post by Michael Wild
Michael
Post by Werner Smekal
Hi,
http://avidemux.org/admForum/viewtopic.php?id=5802
where it is mentioned that: "However, cmake "thinks" that the SDL.framework is already inside the bundle (and therefore doesn't copy it), but cmake can't find it in the next step."
Is this a cmake bug, a FindSDL.cmake bug or is it just me :)
Thanks for any help,
Werner
1) Download the SDL and SDL-Mixer Frameworks and copy them to ~/Library/Frameworks
2) Try to find them with
find_package(SDL REQUIRED)
include_directories(${SDL_INCLUDE_DIR})
find_package(SDL_mixer REQUIRED)
include_directories(${SDLMIXER_INCLUDE_DIR})
SDL_INCLUDE_DIR = /Users/smekal/Library/Frameworks/SDL.framework/Headers
SDL_LIBRARY = /Users/smekal/Library/Frameworks/SDL.framework;-framework Cocoa
SDLMIXER_INCLUDE_DIR = /Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers
SDLMIXER_LIBRARY = /Users/smekal/Library/Frameworks/SDL_mixer.framework
target_link_libraries(
zct
${SDL_LIBRARY}
${SDLMIXER_LIBRARY}
${OPENGL_LIBRARIES}
)
[ 7%] Building CXX object CMakeFiles/zct.dir/src/game/app.cpp.o
/usr/bin/c++ -mmacosx-version-min=10.5 -I/Users/smekal/Library/Frameworks/SDL.framework/Headers -I/Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers -Wall -F/Users/smekal/Library/Frameworks -o CMakeFiles/zct.dir/src/game/app.cpp.o -c /Users/smekal/Development/zct/src/game/app.cpp
"/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake" -E cmake_progress_report /Users/smekal/Development/zct/build/CMakeFiles 2
Linking CXX executable zct.app/Contents/MacOS/zct
"/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/zct.dir/link.txt --verbose=1
/usr/bin/c++ -mmacosx-version-min=10.5 -Wl,-search_paths_first -headerpad_max_install_names CMakeFiles/zct.dir/src/game/app.cpp.o CMakeFiles/zct.dir/src/game/being.cpp.o CMakeFiles/zct.dir/src/game/controller.cpp.o CMakeFiles/zct.dir/src/game/display.cpp.o CMakeFiles/zct.dir/src/game/main.cpp.o CMakeFiles/zct.dir/src/game/map.cpp.o CMakeFiles/zct.dir/src/game/organizer.cpp.o CMakeFiles/zct.dir/src/game/error.cpp.o CMakeFiles/zct.dir/src/game/location.cpp.o CMakeFiles/zct.dir/src/game/pathnode.cpp.o CMakeFiles/zct.dir/src/game/point.cpp.o CMakeFiles/zct.dir/src/game/tile.cpp.o CMakeFiles/zct.dir/src/game/SDLMain.m.o -o zct.app/Contents/MacOS/zct -F/Users/smekal/Library/Frameworks -framework SDL -framework Cocoa -framework SDL_mixer -framework AGL -framework OpenGL
pico:build smekal$ otool -L zct.app/Contents/MacOS/zct
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
@executable_path/../Frameworks/SDL_mixer.framework/Versions/A/SDL_mixer (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 32.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.19.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.54.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.26.0)
_______________________________________________
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
http://www.cmake.org/mailman/listinfo/cmake
--
Dr. Werner Smekal
Institut fuer Angewandte Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: ***@iap.tuwien.ac.at
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
+43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499
Clinton Stimpson
2009-12-15 15:03:23 UTC
Permalink
Post by Werner Smekal
Hi Michael,
Post by Michael Wild
Hi
What is the install-name of SDL.framewor/SDL? What does
otool -L ~/Library/Frameworks/SDL.framework/SDL
tell you? I suspect it is something like
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL
(compatibility version 1.0.0, current version 1.0.0)
....
right? The second line is the one the linker uses to embed as a
reference into your executable. The linker doesn't use it's actual
location, but the library's install name.
Yes that's right. It was actually 5 minutes after I wrote my email,
that I remembered somewhere back in my head, that the library
itself has this reference, so this explains, why the executable
also has this reference.
Post by Michael Wild
Not sure what's going wrong in the CMake part, though...
I assume BundleUtilties uses this reference to copy the libraries
into the app - if the library itself has a "wrong" reference it's
not able to find the library, or?
BundleUtilities/GetPrerequisites will print a warning message if the
framework's id isn't where its really at.
But a few lines down after printing that warning message, it checks
to see if it can find it in ~/Library/Frameworks.
So I suspect its working, but the messages are misleading.
Perhaps the SDL installation shouldn't be setting framework ids like
that.

Clint
Post by Werner Smekal
Post by Michael Wild
IMHO FindSDL.cmake is buggy. The variable SDL_LIBRARY (and all its
siblings) should only contain the framework, not Cocoa. Another
variable, SDL_LIBRARIES (which should be uncached) should then
contain the value of SDL_LIBRARY and all other required supporting
libraries, such as Cocoa on OS X.
For now, what you can do is manually install the SDL framework
using install(DIRECTORY ...) and the first list element of
SDL_LIBRARY.
Thanks, that is what I'm doing right now and this works perfectly.
Also the default XCode project provided by the SDL people does the
same - copying the framework directly into the bundle (without
otooling and install_name_tooling around).
Post by Michael Wild
HTH
Definitely!
Thanks,
Werner
Post by Michael Wild
Michael
Post by Werner Smekal
Hi,
I'm building an application on Mac OS X and link the SDL
libraries into the app. Basically it all works fine (app runs,
etc.), but if I want to use the BundleUtilities to fix/include
the SDL framework into the app bundle I encounter errors. Problem
is, that the references to the SDL libraries in the executable
the SDL Frameworks are not there (see below). BundleUtilities is
then not able to find the SDL Frameworks. In my opinion the
references should point to ~/Library/Frameworks. I wonder why
this app runs, but maybe Mac OS X looks for other standard
locations if it doesn't find the library. I googled around but
http://avidemux.org/admForum/viewtopic.php?id=5802
where it is mentioned that: "However, cmake "thinks" that the
SDL.framework is already inside the bundle (and therefore doesn't
copy it), but cmake can't find it in the next step."
Is this a cmake bug, a FindSDL.cmake bug or is it just me :)
Thanks for any help,
Werner
1) Download the SDL and SDL-Mixer Frameworks and copy them to ~/
Library/Frameworks
2) Try to find them with
find_package(SDL REQUIRED)
include_directories(${SDL_INCLUDE_DIR})
find_package(SDL_mixer REQUIRED)
include_directories(${SDLMIXER_INCLUDE_DIR})
SDL_INCLUDE_DIR = /Users/smekal/Library/Frameworks/SDL.framework/
Headers
SDL_LIBRARY = /Users/smekal/Library/Frameworks/SDL.framework;-
framework Cocoa
SDLMIXER_INCLUDE_DIR = /Users/smekal/Library/Frameworks/
SDL_mixer.framework/Headers
SDLMIXER_LIBRARY = /Users/smekal/Library/Frameworks/
SDL_mixer.framework
target_link_libraries(
zct
${SDL_LIBRARY}
${SDLMIXER_LIBRARY}
${OPENGL_LIBRARIES}
)
[ 7%] Building CXX object CMakeFiles/zct.dir/src/game/app.cpp.o
/usr/bin/c++ -mmacosx-version-min=10.5 -I/Users/smekal/Library/
Frameworks/SDL.framework/Headers -I/Users/smekal/Library/
Frameworks/SDL_mixer.framework/Headers -Wall -F/Users/smekal/
Library/Frameworks -o CMakeFiles/zct.dir/src/game/app.cpp.o -c /
Users/smekal/Development/zct/src/game/app.cpp
"/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake" -
E cmake_progress_report /Users/smekal/Development/zct/build/
CMakeFiles 2
Linking CXX executable zct.app/Contents/MacOS/zct
"/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake" -
E cmake_link_script CMakeFiles/zct.dir/link.txt --verbose=1
/usr/bin/c++ -mmacosx-version-min=10.5 -Wl,-search_paths_first
-headerpad_max_install_names CMakeFiles/zct.dir/src/game/
app.cpp.o CMakeFiles/zct.dir/src/game/being.cpp.o CMakeFiles/
zct.dir/src/game/controller.cpp.o CMakeFiles/zct.dir/src/game/
display.cpp.o CMakeFiles/zct.dir/src/game/main.cpp.o CMakeFiles/
zct.dir/src/game/map.cpp.o CMakeFiles/zct.dir/src/game/
organizer.cpp.o CMakeFiles/zct.dir/src/game/error.cpp.o
CMakeFiles/zct.dir/src/game/location.cpp.o CMakeFiles/zct.dir/src/
game/pathnode.cpp.o CMakeFiles/zct.dir/src/game/point.cpp.o
CMakeFiles/zct.dir/src/game/tile.cpp.o CMakeFiles/zct.dir/src/
game/SDLMain.m.o -o zct.app/Contents/MacOS/zct -F/Users/smekal/
Library/Frameworks -framework SDL -framework Cocoa -framework
SDL_mixer -framework AGL -framework OpenGL
pico:build smekal$ otool -L zct.app/Contents/MacOS/zct
@executable_path/../Frameworks/SDL.framework/Versions/A/
SDL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/
Cocoa (compatibility version 1.0.0, current version 12.0.0)
@executable_path/../Frameworks/SDL_mixer.framework/Versions/A/
SDL_mixer (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/
OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 111.1.4)
/System/Library/Frameworks/CoreServices.framework/Versions/A/
CoreServices (compatibility version 1.0.0, current version 32.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/
CoreFoundation (compatibility version 150.0.0, current version
476.19.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/
AppKit (compatibility version 45.0.0, current version 949.54.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/
A/ApplicationServices (compatibility version 1.0.0, current
version 34.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/
Foundation (compatibility version 300.0.0, current version 677.26.0)
_______________________________________________
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
http://www.cmake.org/mailman/listinfo/cmake
--
Dr. Werner Smekal
Institut fuer Angewandte Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
+43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499
_______________________________________________
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
http://www.cmake.org/mailman/listinfo/cmake
Michael Jackson
2009-12-15 15:23:35 UTC
Permalink
Post by Clinton Stimpson
Post by Werner Smekal
Hi Michael,
Post by Michael Wild
Hi
What is the install-name of SDL.framewor/SDL? What does
otool -L ~/Library/Frameworks/SDL.framework/SDL
tell you? I suspect it is something like
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL
(compatibility version 1.0.0, current version 1.0.0)
....
right? The second line is the one the linker uses to embed as a
reference into your executable. The linker doesn't use it's actual
location, but the library's install name.
Yes that's right. It was actually 5 minutes after I wrote my email,
that I remembered somewhere back in my head, that the library
itself has this reference, so this explains, why the executable
also has this reference.
Post by Michael Wild
Not sure what's going wrong in the CMake part, though...
I assume BundleUtilties uses this reference to copy the libraries
into the app - if the library itself has a "wrong" reference it's
not able to find the library, or?
BundleUtilities/GetPrerequisites will print a warning message if the
framework's id isn't where its really at.
But a few lines down after printing that warning message, it checks
to see if it can find it in ~/Library/Frameworks.
So I suspect its working, but the messages are misleading.
Perhaps the SDL installation shouldn't be setting framework ids like
that.
Clint
I think the SDL developers are just being a bit "too" slick. They are
setting up SDL for Xcode development where typically you would link to
the SDL and then have a "Copy Files Phase" where you copy the
framework into the Application Bundle that resides in the build
directory. All the tutorials regarding Xcode and embedding frameworks
have you do it this way). So the SDL folks made the reasonable
assumption that one would be using Xcode on OS X and they could do it
this way.

This probably explains why OS X developers coming to CMake keep
wanting to copy the framework into the App bundle at build time and
not wait for "Install" time like CMake basically has us doing now.
Just a different way of accomplishing the same thing but it does come
with caveats.

The OP will probably have to add a custom_command to copy the SDL
framework into the .app bundle after building. Then the OP should
verify that when the .app package gets copied to the install location
that the entire .app package is copied, which will bring with it the
SDL framework and so BundleUtilities will just basically skip past the
SDL fixup/copy because it is already "correct".

Just my thoughts.
_________________________________________________________
Mike Jackson ***@bluequartz.net
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
Glenn Hughes
2009-12-15 22:46:36 UTC
Permalink
I think the SDL developers are just being a bit "too" slick. They are setting up SDL for Xcode development where typically you would link to the SDL and then have a "Copy Files Phase" where you copy the framework into the Application Bundle that resides in the build directory.
Its a cultural difference also. Mac developers think of creating the
complete application as part of the build process. A Mac app generally
contains everything it needs so you can just drag it to another
machine and run it. I would never want a half-baked app that is wired
into my machine. Copying the libraries into the app isn't part of
"installation", its part of "building"... Copying the app somewhere
else is "installation" i.e. a no-op as far as my build process is
concerned.

G
Michael Wild
2009-12-16 06:48:36 UTC
Permalink
Post by Glenn Hughes
I think the SDL developers are just being a bit "too" slick. They are setting up SDL for Xcode development where typically you would link to the SDL and then have a "Copy Files Phase" where you copy the framework into the Application Bundle that resides in the build directory.
Its a cultural difference also. Mac developers think of creating the
complete application as part of the build process. A Mac app generally
contains everything it needs so you can just drag it to another
machine and run it. I would never want a half-baked app that is wired
into my machine. Copying the libraries into the app isn't part of
"installation", its part of "building"... Copying the app somewhere
else is "installation" i.e. a no-op as far as my build process is
concerned.
G
In the case of OS X bundles, don't think of it like "installation". It's more like "finishing up".

How about adding some logic to target_link_libraries that writes a file, similar to depend.internal, mapping the install-name of the linked libraries to their location (if a full path has been used for linking). This file could then be used by BundleUtilities.cmake. Probably one would need to black-list certain directories (such as /System/Library/Frameworks), or is this already done?

Michael
David Cole
2009-12-16 12:00:05 UTC
Permalink
Post by Glenn Hughes
Post by Michael Jackson
I think the SDL developers are just being a bit "too" slick. They are
setting up SDL for Xcode development where typically you would link to the
SDL and then have a "Copy Files Phase" where you copy the framework into the
Application Bundle that resides in the build directory.
Post by Glenn Hughes
Its a cultural difference also. Mac developers think of creating the
complete application as part of the build process. A Mac app generally
contains everything it needs so you can just drag it to another
machine and run it. I would never want a half-baked app that is wired
into my machine. Copying the libraries into the app isn't part of
"installation", its part of "building"... Copying the app somewhere
else is "installation" i.e. a no-op as far as my build process is
concerned.
G
In the case of OS X bundles, don't think of it like "installation". It's
more like "finishing up".
How about adding some logic to target_link_libraries that writes a file,
similar to depend.internal, mapping the install-name of the linked libraries
to their location (if a full path has been used for linking). This file
could then be used by BundleUtilities.cmake. Probably one would need to
black-list certain directories (such as /System/Library/Frameworks), or is
this already done?
BundleUtilities avoids copying "system" files -- they are expected to be
installed everywhere by virtue of the fact that they "belong" to the OS.
Files in /System do not get copied in by default with the BundleUtilitles
fixup routines.

Most of our examples of using BundleUtilities occur at "make install" time
via cmake scripts, but you could just as easily use them as part of a
post-build custom command step on your bundle, as long as all of the
dependent pieces are ready to be assembled.

HTH,
David

Loading...