As subject says… it’s possible?
I’ve seen that to build binaries from the command line with 10.2
compatibility on 10.3 I’ve to use -nostdlib and compile and link with
the stuff in the /Developer/SDKs/ (headers and libraries), but how to do
it in the autoconf/automake enviroment?
Bye,
Gabry
As subject says… it’s possible?
I’ve seen that to build binaries from the command line with 10.2
compatibility on 10.3 I’ve to use -nostdlib and compile and link with
the stuff in the /Developer/SDKs/ (headers and libraries), but how to
do it in the autoconf/automake enviroment?
Just build them like you would build any other autoconf/automake based
package. There is no need for any special options to get 10.2
compatible libs this way, AFAIK.
Bye,
MaxAm 01.09.2004 um 13:18 schrieb Gabriele Greco:
Max Horn wrote:
I’ve seen that to build binaries from the command line with 10.2
compatibility on 10.3 I’ve to use -nostdlib and compile and link with
the stuff in the /Developer/SDKs/ (headers and libraries), but how to
do it in the autoconf/automake enviroment?Just build them like you would build any other autoconf/automake based
package. There is no need for any special options to get 10.2 compatible
libs this way, AFAIK.
After a few very slow checks (I’ve access only to 10.3 machines, so
every test needed an email exchange…) I’ve found the problem is not in
SDL itself, the problem is with SDL_ttf that uses freetype and the
freetype version shipped with the 10.3 version of X11 is for 10.3 only.
Sadly on OSX is not possible to build static executables… 
Now I’m trying to write replacements for all the missing libSystem
functions used in libfreetype.a (basically mostly wide character support
stuff like wclen, wsprintf…), maybe it will be easier if I could find
the OLD 10.2 X11 developer SDK archive and grab freetype from there, but
I’ve googled for it for about an hour without luck
Anyone can point me an URL where I can find apple X11 0.3 SDK package?
It’s very difficult to write code compatible with different OSX
versions, since also the “cross-development” Xcode options don’t produce
correct results if you link with “alien” libraries…
I’ve had better results working at hand on the makefile disabling the
standard header and library search path of gcc and adding the
/Develop/SDKs/ one…
Bye,
Gabry
Max Horn wrote:
I’ve seen that to build binaries from the command line with 10.2
compatibility on 10.3 I’ve to use -nostdlib and compile and link with
the stuff in the /Developer/SDKs/ (headers and libraries), but how to
do it in the autoconf/automake enviroment?Just build them like you would build any other autoconf/automake based
package. There is no need for any special options to get 10.2 compatible
libs this way, AFAIK.
After a few very slow checks (I’ve access only to 10.3 machines, so
every test needed an email exchange…) I’ve found the problem is not in
SDL itself, the problem is with SDL_ttf that uses freetype and the
freetype version shipped with the 10.3 version of X11 is for 10.3 only.
Sadly on OSX is not possible to build static executables…
Now I’m trying to write replacements for all the missing libSystem
functions used in libfreetype.a (basically mostly wide character support
stuff like wclen, wsprintf…), maybe it will be easier if I could find
the OLD 10.2 X11 developer SDK archive and grab freetype from there, but
I’ve googled for it for about an hour without luck
Anyone can point me an URL where I can find apple X11 0.3 SDK package?
It’s very difficult to write code compatible with different OSX
versions, since also the “cross-development” Xcode options don’t produce
correct results if you link with “alien” libraries…
I’ve had better results working at hand on the makefile disabling the
standard header and library search path of gcc and adding the
/Develop/SDKs/ one…
Bye,
Gabry
Max Horn wrote:
I’ve seen that to build binaries from the command line with 10.2
compatibility on 10.3 I’ve to use -nostdlib and compile and link
with the stuff in the /Developer/SDKs/ (headers and libraries), but
how to do it in the autoconf/automake enviroment?Just build them like you would build any other autoconf/automake
based package. There is no need for any special options to get 10.2
compatible libs this way, AFAIK.After a few very slow checks (I’ve access only to 10.3 machines, so
every test needed an email exchange…) I’ve found the problem is not
in
SDL itself, the problem is with SDL_ttf that uses freetype and the
freetype version shipped with the 10.3 version of X11 is for 10.3 only.
I recommend installing freetype using DarwinPorts or Fink.
I personally don’t want to develop using XCode and all that jazz. But I
do recommend shipping binaries in a Mac OS X application bundle with
all the bells and whistles like linking with Mac OS X frameworks
instead of using the traditional unix way of linking.
If you’re turned off by distributing your binaries that way, perhaps
you could include a link to download DarwinPorts, and during
installation you could have your program install freetype from source
using the port command.
Sadly on OSX is not possible to build static executables…
It is possible, it’s just very difficult (though technically there are
a few dynamic lirbaries you must link to, but if you try hard enough
you can statically link almost all your libraries.)
Now I’m trying to write replacements for all the missing libSystem
functions used in libfreetype.a (basically mostly wide character
support
stuff like wclen, wsprintf…), maybe it will be easier if I could find
the OLD 10.2 X11 developer SDK archive and grab freetype from there,
but
I’ve googled for it for about an hour without luck
That seems like a difficult way to get FreeType.
Anyone can point me an URL where I can find apple X11 0.3 SDK package?
It’s very difficult to write code compatible with different OSX
versions, since also the “cross-development” Xcode options don’t
produce
correct results if you link with “alien” libraries…
I don’t understand, what build tools are you using? Are you using XCode
or not?
I’ve had better results working at hand on the makefile disabling the
standard header and library search path of gcc and adding the
/Develop/SDKs/ one…
Again I recommend using DarwinPorts. You shouldn’t have any problems
there.On Sep 10, 2004, at 12:09 PM, Gabriele Greco wrote:
Donny Viszneki wrote:
I recommend installing freetype using DarwinPorts or Fink.
I want to give the user an executable that can run on a vanilla Mac, no
extra library should be used, and if it’s used should be bundled as
dynlib or statically linked with the game.
I personally don’t want to develop using XCode and all that jazz. But I
do recommend shipping binaries in a Mac OS X application bundle with all
the bells and whistles like linking with Mac OS X frameworks instead of
using the traditional unix way of linking.
I also prefer developing with GVIM and makefiles, but I’ve built also an
Xcode project hoping to be able to handle the crosscompatiblity issues
without too much hassle…
If you’re turned off by distributing your binaries that way, perhaps you
could include a link to download DarwinPorts, and during installation
you could have your program install freetype from source using the port
command.
Too complex, I’ve almost finished the port of a commercial PC game to
linux and OSX, I use SDL, SDL_mixer & SDL_ttf. The game should have an
application bundle and should run out of the box.
It is possible, it’s just very difficult (though technically there are a
few dynamic lirbaries you must link to, but if you try hard enough you
can statically link almost all your libraries.)
Well the only library I need that I cannot static link it’s the
libSystem… It’s that one that had a lot of changes in the 10.2 -> 10.3
jump.
That seems like a difficult way to get FreeType.
It is, maybe it’s easier to downgrade my development system to 10.2 
I don’t understand, what build tools are you using? Are you using XCode
or not?
My project works with and without xcode.
Again I recommend using DarwinPorts. You shouldn’t have any problems there.
Just looked at the site, it’s very similar to fink, also I could not
find in the guide a point where it says that the packages are compatible
versions of OSX different from the hosting one. Fink for instance has 3
different package bases one for each of the OSX major release…
Bye,
Gabry
PS: Before someone asks it: YES, I know the LGPL library and if I’ll
link something statically I’ll distribute also in the game CD a
libgame.a with a makefile to build the game with the host libraries (the
game is already built this way )
Donny Viszneki wrote:
I recommend installing freetype using DarwinPorts or Fink.
I want to give the user an executable that can run on a vanilla Mac,
no extra library should be used, and if it’s used should be bundled as
dynlib or statically linked with the game.
Did you know you can easily bundle Mac OS X frameworks in the
application bundles? That’s really what I was leaning toward in my last
email but I wasn’t very clear
I personally don’t want to develop using XCode and all that jazz. But
I do recommend shipping binaries in a Mac OS X application bundle
with all the bells and whistles like linking with Mac OS X frameworks
instead of using the traditional unix way of linking.I also prefer developing with GVIM and makefiles, but I’ve built also
an Xcode project hoping to be able to handle the crosscompatiblity
issues without too much hassle…
Awesome, me too. Though lately doing collaborative work I’ve been using
Hydra (SubEthaEdit) I wish I knew how to run vim using that
server-client thing I’ve been told it supports so I could
collaboratively edit in vim, that would rock.
If you’re turned off by distributing your binaries that way, perhaps
you could include a link to download DarwinPorts, and during
installation you could have your program install freetype from source
using the port command.Too complex, I’ve almost finished the port of a commercial PC game to
linux and OSX, I use SDL, SDL_mixer & SDL_ttf. The game should have an
application bundle and should run out of the box.
It’s not really complex at all - but it would add a lot of installer
time that typical users aren’t accustomed to. You could probably build
your own framework from the latest source release fetched using
DarwinPorts.
It is possible, it’s just very difficult (though technically there
are a few dynamic lirbaries you must link to, but if you try hard
enough you can statically link almost all your libraries.)Well the only library I need that I cannot static link it’s the
libSystem… It’s that one that had a lot of changes in the 10.2 ->
10.3 jump.That seems like a difficult way to get FreeType.
It is, maybe it’s easier to downgrade my development system to 10.2
I don’t understand, what build tools are you using? Are you using
XCode or not?My project works with and without xcode.
Again I recommend using DarwinPorts. You shouldn’t have any problems
there.Just looked at the site, it’s very similar to fink, also I could not
find in the guide a point where it says that the packages are
compatible versions of OSX different from the hosting one. Fink for
instance has 3 different package bases one for each of the OSX major
release…
Using DarwinPorts you typically get the latest release source code,
which has been checked to build and run correctly on all versions of
Mac OS X and most Darwin environments.On Sep 10, 2004, at 12:49 PM, Gabriele Greco wrote:
Bye,
GabryPS: Before someone asks it: YES, I know the LGPL library and if I’ll
link something statically I’ll distribute also in the game CD a
libgame.a with a makefile to build the game with the host libraries
(the game is already built this way
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Max Horn wrote:
I’ve seen that to build binaries from the command line with 10.2
compatibility on 10.3 I’ve to use -nostdlib and compile and link
with the stuff in the /Developer/SDKs/ (headers and libraries), but
how to do it in the autoconf/automake enviroment?Just build them like you would build any other autoconf/automake
based package. There is no need for any special options to get 10.2
compatible libs this way, AFAIK.After a few very slow checks (I’ve access only to 10.3 machines, so
every test needed an email exchange…) I’ve found the problem is not
in SDL itself, the problem is with SDL_ttf that uses freetype and the
freetype version shipped with the 10.3 version of X11 is for 10.3
only.Sadly on OSX is not possible to build static executables…
Yes, this is possible. I am doing it regulary for Exult and ScummVM.
Look at README.MacOSX (part of the SDL sources) for some information on
how to do it. For ScummVM (hosted at SF.net), there is a separate
target (look at the main “Makefile”).
In the case of Exult, I was (and still am) too lazy to change the
automake based build system to provide a “static” target, so I manually
link the static binary there. To do that, I simply copy the regular
linker command the auto* build system produces, and replace the output
of “sdl-config --libs” in it by that of “sdl-config --static-libs”
Now I’m trying to write replacements for all the missing libSystem
functions used in libfreetype.a (basically mostly wide character
support stuff like wclen, wsprintf…), maybe it will be easier if I
could find the OLD 10.2 X11 developer SDK archive and grab freetype
from there, but I’ve googled for it for about an hour without luck
You do not have to static link libSystem. In fact you never never
never should do that. It’s like trying to static link libc, or even the
kernel – it simply doesn’t make sense :-).
Bye,
MaxAm 10.09.2004 um 18:09 schrieb Gabriele Greco:
Max Horn wrote:
In the case of Exult, I was (and still am) too lazy to change the
automake based build system to provide a “static” target, so I manually
link the static binary there. To do that, I simply copy the regular
linker command the auto* build system produces, and replace the output
of “sdl-config --libs” in it by that of “sdl-config --static-libs”
Yes, I’ve looked at the exult makefile, and I’ve no problem in making
SDL static (but I don’t need it since I include the framework in
my.app/Contents/Framework)
You do not have to static link libSystem. In fact you never never
never should do that. It’s like trying to static link libc, or even the
kernel – it simply doesn’t make sense :-).
It has sense, the 10.2 libSystem miss a lot of functions the 10.3 one
has. For instance the whole support of wide characters ansi99 functions
(wmemset, wmemcpy, wcslen, swprintf…).
I had to write replacements for those functions in my binary since the
game I’m working on widely use std::wstring (and the char_traits of
wstring uses the whole wmem* family internally)… and finally I got
everything to work ok.
If static link (of libSystem) on Mac was an option that mass would have
been far easier
About the linux version I’m quite sure I’ll have to make a static
binary, I use SDL 1.2.7 features (SDL_HasMMX() and similar…) and most
distributions still have 1.2.6 or lower. Also the machines I use are all
based on libc 2.3 and I’d like to provide compatibility also with libc
2.1…
Bye,
Gabry
Max Horn wrote:
In the case of Exult, I was (and still am) too lazy to change the
automake based build system to provide a “static” target, so I
manually link the static binary there. To do that, I simply copy the
regular linker command the auto* build system produces, and replace
the output of “sdl-config --libs” in it by that of “sdl-config
–static-libs”Yes, I’ve looked at the exult makefile, and I’ve no problem in making
SDL static (but I don’t need it since I include the framework in
my.app/Contents/Framework)You do not have to static link libSystem. In fact you never never
never should do that. It’s like trying to static link libc, or even
the kernel – it simply doesn’t make sense :-).It has sense, the 10.2 libSystem miss a lot of functions the 10.3 one
has. For instance the whole support of wide characters ansi99
functions (wmemset, wmemcpy, wcslen, swprintf…).
OK, but to that problem, static linking libSystem isn’t a solution, I
am afraid. You’ll probably have to provide two binaries, I am afraid,
one for 10.2 and one for 10.3.
I had to write replacements for those functions in my binary since the
game I’m working on widely use std::wstring (and the char_traits of
wstring uses the whole wmem* family internally)… and finally I got
everything to work ok.
Well, then why not use those wrappers on 10.3, too, should solve your
problem… ? Build the app on 10.2, using your replacement code, and
then the resulting binary should still work fine on 10.3
If static link (of libSystem) on Mac was an option that mass would
have been far easierAbout the linux version I’m quite sure I’ll have to make a static
binary, I use SDL 1.2.7 features (SDL_HasMMX() and similar…) and
most distributions still have 1.2.6 or lower. Also the machines I use
are all based on libc 2.3 and I’d like to provide compatibility also
with libc 2.1…
Yes, but here you are just static linking SDL (see above); you are not
static linking the kernel.
Bye,
MaxAm 20.09.2004 um 09:59 schrieb Gabriele Greco:
Max Horn wrote:
OK, but to that problem, static linking libSystem isn’t a solution, I am
afraid. You’ll probably have to provide two binaries, I am afraid, one
for 10.2 and one for 10.3.
What I actually do is to compile (on my 10.3.x mac) with SDKROOT set to
the 10.2.x headers and libraries and link together with my function
replacements, I get a few duplicated symbols warning but my binary
finally works with both versions of OSX!
About the linux version I’m quite sure I’ll have to make a static
binary, I use SDL 1.2.7 features (SDL_HasMMX() and similar…) and
most distributions still have 1.2.6 or lower. Also the machines I use
are all based on libc 2.3 and I’d like to provide compatibility also
with libc 2.1…
Yes, but here you are just static linking SDL (see above); you are not
static linking the kernel.
I’m not speaking about sdl-config --static-libs, but to do something like:
g++ -o exec -static …
I don’t see a big difference in static link the glibc and static link
libSystem on OSX, but I can be wrong!
Bye,
Gabry
Max Horn wrote:
OK, but to that problem, static linking libSystem isn’t a solution, I
am afraid. You’ll probably have to provide two binaries, I am afraid,
one for 10.2 and one for 10.3.What I actually do is to compile (on my 10.3.x mac) with SDKROOT set
to the 10.2.x headers and libraries and link together with my function
replacements, I get a few duplicated symbols warning but my binary
finally works with both versions of OSX!About the linux version I’m quite sure I’ll have to make a static
binary, I use SDL 1.2.7 features (SDL_HasMMX() and similar…) and
most distributions still have 1.2.6 or lower. Also the machines I
use are all based on libc 2.3 and I’d like to provide compatibility
also with libc 2.1…
Yes, but here you are just static linking SDL (see above); you are
not static linking the kernel.I’m not speaking about
sdl-config --static-libs, but to do something
like:g++ -o exec -static …
This will not produce a static linked binary, though, at least not on
OSX. I strongly recommend you read up on the command switch “-static”,
e.g. via “man g++”.
Bye,
MaxAm 21.09.2004 um 13:07 schrieb Gabriele Greco:
Max Horn wrote:
About the linux version I’m quite sure I’ll have to make a static
binary, I use SDL 1.2.7 features (SDL_HasMMX() and similar…) and
most distributions still have 1.2.6 or lower. Also the machines I use
are all based on libc 2.3 and I’d like to provide compatibility also
with libc 2.1…
That’s silly. People can update SDL to play your game. Heck, people
SHOULD update SDL to play your game.On Sep 20, 2004, at 3:59 AM, Gabriele Greco wrote:
I like to point out that I had just about zero support issues since I
startet to provide statically linked binaries (using the loki
installer). Of course, the build process for the binary requires,
among other things, the sacrifice of a goat. E.g. here’s my LIBS
line:
LIBS = -L/usr/X11R6/lib -L/usr/local/lib
-Wl,-rpath,/usr/local/lib,-Bstatic -lSDL_sound -lSDL -lsmpeg -lmikmod
-lvorbisfile -lvorbis -logg -lXxf86dga -lXxf86vm -lXv -lXinerama -lXi
-lpng -lz -lstdc++ -Wl,-Bdynamic -lpthread -lGL -lX11 -lXext -ldl
Bottom line: If you want that people play your game, don’t make them
go through the hoops of a) installing a gazillion dependencies and b)
upgrade everything to the bleeding edge.
Max Horn wrote:
About the linux version I’m quite sure I’ll have to make a static
binary, I use SDL 1.2.7 features (SDL_HasMMX() and similar…) and
most distributions still have 1.2.6 or lower. Also the machines I use
are all based on libc 2.3 and I’d like to provide compatibility also
with libc 2.1…That’s silly. People can update SDL to play your game. Heck, people
SHOULD update SDL to play your game.
Max Horn wrote:
About the linux version I’m quite sure I’ll have to make a static
binary, I use SDL 1.2.7 features (SDL_HasMMX() and similar…) and
most distributions still have 1.2.6 or lower. Also the machines I use
are all based on libc 2.3 and I’d like to provide compatibility also
with libc 2.1…That’s silly. People can update SDL to play your game. Heck, people
SHOULD update SDL to play your game.
While I understand your point of view, the fact is that people like to
only upgrade when their distro tells them to upgrade. Not to mention
that the more work people have to do to get a game to run the less
likely they are to play the game. If the goal is to get people to play
your game, and it is, then you have to do whatever you can to make it
easy to play your game.
I think he really does need to create a static binary for Linux. I hope
he also provides a .deb file that is not statically linked so that
people like me can just install it and have all the dependencies taken
care of. (Yeah, I’m one of those nasty debianistas… )
Bob PendletonOn Wed, 2004-09-22 at 21:05, Donny Viszneki wrote:
On Sep 20, 2004, at 3:59 AM, Gabriele Greco wrote:
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
Andreas Umbach wrote:
Of course, the build process for the binary requires,
among other things, the sacrifice of a goat. E.g. here’s my LIBS
line:LIBS = -L/usr/X11R6/lib -L/usr/local/lib
-Wl,-rpath,/usr/local/lib,-Bstatic -lSDL_sound -lSDL -lsmpeg -lmikmod
-lvorbisfile -lvorbis -logg -lXxf86dga -lXxf86vm -lXv -lXinerama -lXi
-lpng -lz -lstdc++ -Wl,-Bdynamic -lpthread -lGL -lX11 -lXext -ldl
How can I find out what libs I’d have to include and in which order? I
have written a game myself and can’t get a static version to work.
Max Horn wrote:
About the linux version I’m quite sure I’ll have to make a static
binary, I use SDL 1.2.7 features (SDL_HasMMX() and similar…) and
most distributions still have 1.2.6 or lower. Also the machines I use
are all based on libc 2.3 and I’d like to provide compatibility also
with libc 2.1…That’s silly. People can update SDL to play your game. Heck, people
SHOULD update SDL to play your game.I like to point out that I had just about zero support issues since I
startet to provide statically linked binaries
…snip…
Bottom line: If you want that people play your game, don’t make them
go through the hoops of a) installing a gazillion dependencies and b)
upgrade everything to the bleeding edge.
I hadn’t thought of it from a support perspective. Although, it’s easy
enough to throw a dll into a Windows install, and also very easy to put
a framework into a Mac OS X .app bundle. No static linking so far.
And if you’re a Linux or BSD user, are you really going to be whining
to the author of every piece of software you have a hard time
building/installing on your system? What kind of a wimp does that?
(Although I am sort of kidding here, my point still stands: a Linux or
BSD user should be competent enough to get a reasonably new version of
SDL installed.)On Sep 23, 2004, at 3:26 AM, Andreas Umbach wrote:
On Wed, 22 Sep 2004 22:05:39 -0400, Donny Viszneki wrote:
On Sep 23, 2004, at 9:46 AM, Bob Pendleton wrote:
While I understand your point of view, the fact is that people like to
only upgrade when their distro tells them to upgrade. Not to mention
that the more work people have to do to get a game to run the less
likely they are to play the game. If the goal is to get people to play
your game, and it is, then you have to do whatever you can to make it
easy to play your game.
I am unfamiliar with this sort of person. I have heard of these people,
but I have yet to meet them. Given how EASY it is to update on most
distros (emerge this, port install that, etc etc) why can’t these
people be expected to update SDL once in a while (say, perhaps, when
they download a new “bleeding edge” SDL game?) I’m still running on
1.2.7 release, and IIRC, that came out well over a month ago.
Another way of looking at it: does a cutting-edge SDL game’s
development to its first /release version/ actually take less time than
the typical release cycle of SDL?
This forces people to upgrade lots of individual applications, when they
want to upgrade a single library. That’s a major point of dynamic linking.
It also locks them into your configuration of libraries. For example,
they may use ALSA, and have SDL compiled against it; if your ALSA library
doesn’t support it, you’re forcing them to enable those ugly OSS
compatibility modules. The alternative is worse: if they use OSS and your
binaries use ALSA, it won’t work since the ALSA libraries won’t be found.
This also has security implications: upgrade a library to fix a security-
related bug and you have individual statically-linked apps that weren’t
upgraded, that you may not even know use the library. (Whether this
matters depends on the application.)
In my experience, requiring fundamental deps, which are generally
available and widely-used, is fine. My testing snapshots require
libz, libpng, libvorbis/ogg/vorbisfile, MAD, SDL and jpeg (and GL
and X); all of these are available in every useful distribution,
and most of them are always installed already anyway.
I statically link ffmpeg and libresample, though, since they’re not
nearly as widely available, and ffmpeg moves a lot, so I like to make
sure that bugs related to it are reproducable.On Thu, Sep 23, 2004 at 09:26:43AM +0200, Andreas Umbach wrote:
I like to point out that I had just about zero support issues since I
startet to provide statically linked binaries (using the loki
installer). Of course, the build process for the binary requires,
among other things, the sacrifice of a goat. E.g. here’s my LIBS
line:LIBS = -L/usr/X11R6/lib -L/usr/local/lib
-Wl,-rpath,/usr/local/lib,-Bstatic -lSDL_sound -lSDL -lsmpeg -lmikmod
-lvorbisfile -lvorbis -logg -lXxf86dga -lXxf86vm -lXv -lXinerama -lXi
-lpng -lz -lstdc++ -Wl,-Bdynamic -lpthread -lGL -lX11 -lXext -ldl
–
Glenn Maynard
The general point is that the less you demand of the user, the more
likely that the user will want to use the software.
It may be easy to upgrade packages (and it is), but something that
"just works" is even easier, and even easier is better when dealing
with consumers.
So the goal is clear. The execution perhaps less so.
ChrisOn Thu, 23 Sep 2004 12:49:21 -0400, Donny Viszneki wrote:
I am unfamiliar with this sort of person. I have heard of these people,
but I have yet to meet them. Given how EASY it is to update on most
distros (emerge this, port install that, etc etc) why can’t these
people be expected to update SDL once in a while (say, perhaps, when
they download a new “bleeding edge” SDL game?) I’m still running on
1.2.7 release, and IIRC, that came out well over a month ago.
–
Chris Nystrom
http://www.newio.org/~ccn
AIM: nystromchris
P.S. I have 3 Gmail invites available. Please e-mail me if you want one.