SDL troubles on Mac OS X

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

SDL troubles on Mac OS X

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 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)


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: SDL troubles on Mac OS X

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

/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

On 15. Dec, 2009, at 8:51 , Werner Smekal wrote:

> 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)
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: SDL troubles on Mac OS X

Werner Smekal
Hi Michael,


On 12/15/09 9:58 AM, Michael Wild wrote:

> 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.

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.

>
> 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?
>
> 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).

>
> HTH

Definitely!

Thanks,
Werner

>
> Michael
>
> On 15. Dec, 2009, at 8:51 , Werner Smekal wrote:
>
>> 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)
>>
>>
>> _______________________________________________
>> 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
>

--
Dr. Werner Smekal
Institut fuer Angewandte Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: [hidden email]
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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: SDL troubles on Mac OS X

Clinton Stimpson

On Dec 15, 2009, at 2:31 AM, Werner Smekal wrote:

> Hi Michael,
>
>
> On 12/15/09 9:58 AM, Michael Wild wrote:
>> 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.
>
> 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.
>
>>
>> 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

>>
>> 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).
>
>>
>> HTH
>
> Definitely!
>
> Thanks,
> Werner
>
>>
>> Michael
>>
>> On 15. Dec, 2009, at 8:51 , Werner Smekal wrote:
>>
>>> 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)
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
> --
> Dr. Werner Smekal
> Institut fuer Angewandte Physik
> Technische Universitaet Wien
> Wiedner Hauptstr 8-10
> A-1040 Wien
> Austria
> DVR-Nr: 0005886
>
> email: [hidden email]
> 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
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: SDL troubles on Mac OS X

Michael Jackson

On Dec 15, 2009, at 10:03 AM, Clinton Stimpson wrote:

>
> On Dec 15, 2009, at 2:31 AM, Werner Smekal wrote:
>
>> Hi Michael,
>>
>>
>> On 12/15/09 9:58 AM, Michael Wild wrote:
>>> 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.
>>
>> 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.
>>
>>>
>>> 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                  [hidden email]
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: SDL troubles on Mac OS X

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
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: SDL troubles on Mac OS X

Michael Wild

On 15. Dec, 2009, at 23:46 , Glenn Hughes wrote:

>> 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

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: SDL troubles on Mac OS X

David Cole
On Wed, Dec 16, 2009 at 1:48 AM, Michael Wild <[hidden email]> wrote:

On 15. Dec, 2009, at 23:46 , Glenn Hughes wrote:

>> 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?


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


_______________________________________________
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