New in CVS!
http://www.libsdl.org/cvs.php
You can now build SDL Mac OS X Universal binaries using configure/make on
Mac OS X 10.4, using build-scripts/fatbuild.sh:
sh build-scripts/fatbuild.sh
sudo sh build-scripts/fatbuild.sh install
This is mostly useful for redistributing a Universal dynamic library
with your Univeral binary application, in which case you’d just bundle
libSDL-1.2.0.dylib with your application. I think there are some magic
incantations to make an app load a shared library from the application
path instead of the system library path, but I don’t know them offhand.
If you’re interested, you can look at the script to see how the library
is built against the 10.2 SDK for PowerPC, and the 10.4 SDK for Intel,
which is something you may want to do for your own Universal applications.
Note that this is only for applications linking with SDL as a dynamic
library, not a framework. Eric Wing has already created Xcode projects
for building a Universal framework, which are included in CVS as well.
Enjoy!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
El s?b, 22-04-2006 a las 13:09 -0700, Sam Lantinga escribi?:
I think there are some magic incantations to make an app load a
shared library from the application path instead of the system
library path, but I don’t know them offhand.
I use an ugly hack which consists in running a binary "launcher-game"
which sets the LD_LIBRARY_PATH (or similar) to “.” and spawns the actual
game binary. Ugly but works 
--Gabriel________________________________________________________________________
Gabriel Gambetta
Mystery Studio - http://www.mysterystudio.com
Gabriel on Graphics - http://gabrielongraphics.blogspot.com
Hello !
Great !!!
Please add that also to the SDL Helper Libs.
CU
Sam Lantinga wrote:
I think there are some magic incantations to make an app load a
shared library from the application path instead of the system
library path, but I don’t know them offhand.
You need to set the install_name of the library to something starting
with “@executable_path”. When linking an application to a dynamic
library, the install_name is recorded in the application, and it starts
looking for the library there at run time. See
http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/Articles/OverviewOfDynamicLibraries.html.
Here’s what it is for a framework, but since frameworks are nothing but
dynamic libraries wrapped in a special folder structure, I guess it
should work for naked dylibs too:
myriad:~ cwalther$ otool -D /Library/Frameworks/SDL.framework/SDL
/Library/Frameworks/SDL.framework/SDL:
@executable_path/…/Frameworks/SDL.framework/Versions/A/SDL
For a framework built in Xcode, you achieve this by setting the
INSTALL_PATH build setting to “@executable_path/…/Frameworks”.
(http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/CreatingFrameworks.html#//apple_ref/doc/uid/20002258-106880-BAJJBIEF)
I guess for command-line-built dylibs, you’d do it using the
-install_name option to gcc or libtool. You should also be able to
change it afterwards using install_name_tool.
-Christian
El dom, 23-04-2006 a las 12:03 +0200, Christian Walther escribi?:
You need to set the install_name of the library to something starting
with “@executable_path”.
I tried that before my ugly hack, but for some reason it didn’t
work 
I should try again…
--Gabriel________________________________________________________________________
Gabriel Gambetta
Mystery Studio - http://www.mysterystudio.com
Gabriel on Graphics - http://gabrielongraphics.blogspot.com
Hello Sam,
Saturday, April 22, 2006, 9:09:57 PM, you wrote:
SL> New in CVS!
SL> http://www.libsdl.org/cvs.php
SL> You can now build SDL Mac OS X Universal binaries using configure/make on
SL> Mac OS X 10.4, using build-scripts/fatbuild.sh:
SL> sh build-scripts/fatbuild.sh
SL> sudo sh build-scripts/fatbuild.sh install
SL> This is mostly useful for redistributing a Universal dynamic library
SL> with your Univeral binary application, in which case you’d just bundle
SL> libSDL-1.2.0.dylib with your application. I think there are some magic
SL> incantations to make an app load a shared library from the application
SL> path instead of the system library path, but I don’t know them offhand.
You change the path using install_name_tool. I make a "Frameworks"
path in my app bundle, but you can just as well use Resources or the
executable directory. It’d go something like:
install_name_tool -change /usr/local/lib/libSDL-1.2.0.dylib @executable_path/…/Frameworks/libSDL.dylib $(bundle_name)/Contents/MacOS/AT
Be aware if you use SDL_mixer or any other dylib that depends on SDL,
you have to run install_name_tool on them too.
Nice one Apple. What a completely stupid feature :X–
Best regards,
Peter mailto:@Peter_Mulholland
Peter Mulholland wrote:
You change the path using install_name_tool. I make a "Frameworks"
path in my app bundle, but you can just as well use Resources or the
executable directory. It’d go something like:
install_name_tool -change /usr/local/lib/libSDL-1.2.0.dylib @executable_path/…/Frameworks/libSDL.dylib $(bundle_name)/Contents/MacOS/AT
Yes, that’ll work.
Be aware if you use SDL_mixer or any other dylib that depends on SDL,
you have to run install_name_tool on them too.
This is one way to do it, and it’ll work if the libraries are all installed in
the same place relative to the application.
If that is not the case - for instance, if SDL and SDL_mixer are installed
system-wide and any application should be able to use both of them - it’ll break
down. In that case, you can use install_name_tool to hard-code the absolute
library paths to the place the libraries are installed to.
Nice one Apple. What a completely stupid feature :X
If this sounds badly engineered, consider that all shared libraries under mac os
x are installed at predetermined absolute paths. That makes it more-or-less
impossible to reorganize the file system structure, but it also makes sure you
don’t accidently load the wrong version of a library just because it’s in the
search path.
Regards,
Uli
Nice one Apple. What a completely stupid feature :X
If this sounds badly engineered, consider that all shared libraries
under mac os
x are installed at predetermined absolute paths. That makes it more-
or-less
impossible to reorganize the file system structure, but it also
makes sure you
don’t accidently load the wrong version of a library just because
it’s in the
search path.
I am sure the Apple engineers, whose talent and creativity is
becoming more and more obvious the Windows Vista debacle becomes
almost humorous, gave this a lot of thought and considered the pros
and cons. they did what was safe for end-users even if it create more
work for developers. I think they made the right chocie, though
documenting a bit more openly and widely might have been helpful 
DanielOn Apr 24, 2006, at 1:52, Ulrich von Zadow wrote: