[SDL] SDL & Project Builder

Darrell Walisser walisser at mac.com
Fri Jan 24 16:13:01 PST 2003


First, let me list some things you might want to read:

Manpages:
dyld, ld

HTML docs:
/Developer/Documentation/ReleaseNotes/Prebinding.html
/Developer/Documentation/ReleaseNotes/TwoLevelNamespaces.html

On Friday, January 24, 2003, at 03:01  PM, sdl-request at libsdl.org wrote:

> Message: 35
> Date: Fri, 24 Jan 2003 09:33:13 -0800 (PST)
> From: Eric Wing <ewing2121 at yahoo.com>
> To: sdl at libsdl.org, Johannes Fortmann <J.Fortmann at gmx.de>
> Subject: [SDL] Re: SDL & Project Builder
> Reply-To: sdl at libsdl.org
>
> So one of the things I'm working with right now is
> SDL_sound. The current SDL_sound project doesn't work
> for me because I think it's too old, so I've tried
> creating a new one. SDL_sound depends on a whole lot
> of external codecs (Smpeg, Ogg Vorbis, Mikmod, etc)
> which I also have to build projects for. Furthermore,
> I am building a library that depends on SDL_sound. And
> finally, my application depends on SDL_sound and my
> library.
>
> So one thing I've been trying to understand is this
> field in Target called: "Install Location"
> I noticed all the SDL frameworks select:

> Path: @executable_path/../Frameworks

This corresponds to the -install_name option to ld (see the manpage), 
minus the library name (hence, "install path" rather than "install 
name".

>
> So I decided to copy this field on all my Frameworks
> that I was building. I put it in Ogg, Vorbis, Mikmod,
> SDL_sound, and my app.
>
> However, when I did this, I was able to compile Ogg,
> Vorbis, Mikmod, and SDL_sound okay. But when I got to
> compiling my library, I got an error message like:
> Can't find @executable_path/../Frameworks (does not
> exist) for the codecs (Ogg,Vorbis,Mikmod)

That's strange. I didn't think the install path was checked for 
existence or not at link time. Did you try cleaning the targets and 
recompiling?
>
>
> So I'm confused about this field and what I'm supposed
> to do with it. Why do all the SDL projects set it to
> this path?

So that you can bundle the shared libraries in 
MyApp.app/Contents/Frameworks.

> And does it hurt to leave it to none (i.e.
> can I still drop Frameworks into any of the bundle
> subdirectories)?

You won't be able to drop it in. The dyld manpage explains how dynamic 
libraries are discovered at runtime. The order of the search is (off 
the top of my head, you should check to make sure this is right):

1. The install path (which is linked into the executable, visible with 
otool -L)
2. The standard directories: ~/Library/Frameworks then 
/Library/Frameworks then /System/Library/Frameworks


>
> And also, even though everything otool -L says
> @executable_path/../Frameworks,
> is it possible to drop it into SharedFrameworks
> instead?

No. Not without changing the install path to 
@executable_path/../SharedFrameworks.

>  To me it seems that I would typically want
> the user to use a newer version of SDL if they already
> had it on their system instead of being locked down by
> mine.

In that case, you can just bundle the library installers with your app.

To get what you want would be more complicated (since you're 
customizing the way dyld works), but it is possible. One thing I can 
think of is putting your application code into a framework, and then 
using a bootstrap program to set the DYLD_FRAMEWORK_PATH before you 
load the bundle that contains your program and execute the main 
procedure.

>
> And can you recommend a good system of testing if the
> Frameworks subdirectories work. (It's really hard to
> verify since everything is installed in my regular
> /Library/Frameworks folder too.)
>

I tested by installing everything in ~/Library/Frameworks instead 
(which is what you get if you install just the development runtimes). 
Then create a new user, and log in as that user for testing.





More information about the SDL mailing list