[SDL] SDL_image + libtiff on Windows

Gib Bogle bogle at ihug.co.nz
Wed Jan 29 19:00:01 PST 2003


Thank you Johannes for the great response. I've also
been wondering how I will 
ultimately package my SDL based app for OSX without
making it painful
for the user to install.

But can you go into a little more detail about how you
can bundle frameworks inside
an app using Project Builder? I'm still a little
confused on the issue.
I think I see the Targets/Linker section you
described. I see a section 
for "Search paths", where directories for headers,
frameworks, libraries, 
and java classes can be entered.If I try placing
../Frameworks in the box 
for Frameworks, I get an error that the Framework
cannot be found 
when I try building. I thought this box  was to tell
the system where 
to locate things on your system. And I can't drop it
into the App yet 
because it isn't built. It seems like a
chicken-and-egg problem. Is there 
a separate box to tell it where to look at Run-time?
And is Project Builder 
supposed to create the ../Frameworks (or
../SharedFrameworks)
for you, or do you have to create everything manually.

And is there a way to bundle Frameworks within
frameworks? I would like to build 
a framework (library) that uses SDL and lots of other
libs. 


Thank you,
Eric


> Subject: Re: [SDL] SDL license change AND MacOS X
> dynamic linking
> From: Johannes Fortmann <J.Fortmann at gmx.de>
> > Does anyone have experience creating a dynamically
> linked app for 
> > MacOS X that can share the process with me?
> >
> > As close as I can tell I would have to have the
> user install the SDL 
> > frameworks in their local library folder. (?)
> >
> > Aaron
> >
> 
> Look at your Project Builder project: under
> Targets/Linker settings, 
> you should find a "-framework SDL" in the box "other
> Mach-O Linker 
> Flags". This links your executable against the
> SDL.framework. Note that 
> you should _not_ have the SDL.framework installed in
> your user 
> directory for this: it should be in
> /Library/Frameworks. Otherwise, the 
> path will be hardcoded to your home dir in the
> executable, which is not 
> what you want. (The SDL package installs the
> framework into the home 
> dir by default; this should be changed, perhaps).
> 
> You can examine the dynamically linked libraries in
> Terminal by 
> changing to build/AppName.app/Contents/MacOS and
> doing an otool -L 
> AppName . This gives you an output like this:
> 
> $ otool -L chromium
> chromium:
>         
>
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
> 
> (compatibility version 1.0.0, current version 1.0.0)
>         
>
/Users/jobi/Library/Frameworks/SDL.framework/Versions/A/SDL
> 
> (compatibility version 1.0.0, current version 1.0.0)
>          /usr/lib/libz.1.1.3.dylib (compatibility
> version 1.0.0, current 
> version 1.1.3)
>          
>
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
> 
> (compatibility version 300.0.0, current version
> 425.0.0)
>         
>
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> 
> (compatibility version 45.0.0, current version
> 620.0.0)
>         
>
/System/Library/Frameworks/AGL.framework/Versions/A/AGL
> 
> (compatibility version 1.0.0, current version 1.0.0)
>         
>
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> 
> (compatibility version 2.0.0, current version
> 122.0.0)
> 
> Note that I linked this app with SDL in my home dir.
> With SDL in 
> /Library/Frameworks, this would look like
> 
> $ otool -L enigma
> enigma:
>         
>
@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 8.0.0)
>          
>
@executable_path/../Frameworks/SDL_image.framework/Versions/A/SDL_image
> 
> (compatibility version 1.0.0, current version 1.0.0)
>          
>
@executable_path/../Frameworks/SDL_mixer.framework/Versions/A/SDL_mixer
> 
> (compatibility version 1.0.0, current version 1.0.0)
>          /usr/lib/libSystem.B.dylib (compatibility
> version 1.0.0, 
> current version 63.0.0)
> 
> (here I linked with SDL_image and SDL_mixer
> additionally). You see that 
> the hard coded path for SDL.framework refers to
> ../Frameworks: this 
> means that you can put SDL.framework into you .app
> bundle in 
> AppName.app/Contents/Frameworks, and have it both
> "statically linked" 
> (i.e. always distributed with the .app) and
> exchangeable. The system 
> will, according to documentation, always use the
> framework bundle with 
> the highest version. You want to read 
>
/Developer/Documentation/Essentials/SystemOverview/index.html
> . (Come 
> on. You know you do :-) )
> 
> When porting your app, don't forget that Mac users
> expect your 
> application to be a single bundle. The standard
> SDLMain.m that comes 
> with SDL sadly does the following:
>      if (shouldChdir)
>      {
>        assert ( chdir (parentdir) == 0 );   /* chdir
> to the binary app's 
> parent */
>        assert ( chdir ("../../../") == 0 ); /* chdir
> to the .app's 
> parent */
>      }
> which motivates to store the data in the .app's
> parent directory. I 
> always change this to
>      if (shouldChdir)
>      {
>        assert ( chdir (parentdir) == 0 );   /* chdir
> to the binary app's 
> parent */
>        assert ( chdir ("../Resources/") == 0 ); /*
> chdir to the 
> Resources folder in the .app bundle */
>      }
> and put my stuff into
> AppName.app/Contents/Resources.
> 
> HTH,
> 
> Johannes Fortmann


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com




More information about the SDL mailing list