SDL static linking on windows?

My sdl game on windows requires a few SDL libs, and data files. While I
have created a windows installer to package up these files, I would very
much like to distribute a single self-contained binary.

I think I can just compile in all the data files, or append them, and
access them with physfs or something similar, but so far I haven’t
managed to produce a static executable under windows. I have tried
adding -static or -Bstatic to the gcc line, and replaced all -l
with direct references to /usr/local/lib/lib.a, but the resulting
binary still requires SDL.dll to run.

I hope somebody can point me in the right direction…

CU,
Sec–
Every Software sucks.
But Perl can suck in more ways than
other languages and much less lines of code :wink:

Stefan Sec Zehl wrote:

I think I can just compile in all the data files, or append them, and
access them with physfs or something similar…

Is this just a hypothetical idea, or do you know how to do that? If you
do, I’d be interested in it. I’d like to ship my application as
monolithically as possible too. That’s no problem on my home platform
Mac OS X where you can just put everything in the app bundle, but on
Windows I’m currently shipping my data files in an uncompressed zip
archive next to the application and accessing them with PhysicsFS. I’d
be very interested in integrating this archive in the executable in a
way that still allows it to be accessed through PhysicsFS.

I haven’t attempted statically linking in SDL yet, so I can’t answer
your question, but I’d be interested in the answer too.

By the way, I’m cross-compiling with Mingw - you too, it seems?

-Christian

Stefan Sec Zehl wrote:

I think I can just compile in all the data files, or append them, and
access them with physfs or something similar…

Is this just a hypothetical idea, or do you know how to do that?

I have not done it for my game yet, as it isn’t yet converted to use
physfs. But its a bit more than hypothetical. The dirty version is to
just stick the .exe and the .zip together in one file. This works
because .exe does not care about garbage at the beginning, and zip does
not care about garbage at the end.

If you do, I’d be interested in it. I’d like to ship my application as
monolithically as possible too.

I will keep you informed about my progress on this.

                            That's no problem on my home platform 

Mac OS X where you can just put everything in the app bundle, but on
Windows I’m currently shipping my data files in an uncompressed zip
archive next to the application and accessing them with PhysicsFS.

As you seem to already use physfs. What led you to using ZIP without
compression? Have you compared the different archive formats it
supports?

I haven’t attempted statically linking in SDL yet, so I can’t answer
your question, but I’d be interested in the answer too.

Too bad. I would really appreciate if somebody could shed a bit of light
on that.

By the way, I’m cross-compiling with Mingw - you too, it seems?

I was to lazy to set up a cross-compiler on FreeBSD, so I compile with
cygwin-gcc and “-mno-cygwin -mwindows” on my WinXP Laptop.

CU,
SecOn Fri, Aug 13, 2004 at 09:39 +0200, Christian Walther wrote:

Consider the need for having to type “www.domain.name” a little IQ test
that you have to take before you can access my web site.’ – Wietse

I’d be very interested in integrating this archive in the executable in a
way that still allows it to be accessed through PhysicsFS.

You can append a regular zipfile (compressed or otherwise) to the end of
a Windows .EXE … PhysicsFS (and most every other ZIP processor) will
read the archive back-to-front looking for the “end of central
directory” record; meanwhile Windows reads the .EXE front-to-back, so
this happens to work. This is also how self-extracting .exe files work,
for the record.

It also means you can extract the data by giving the .exe file to WinZip
or whatever, and it’ll think it’s a standard zip with some junk at the
start of the file. It’s kinda a cool hack.

Here’s some example code:
http://svn.icculus.org/cgi-bin/viewcvs/cgi/viewcvs.cgi/physfs/extras/selfextract.c?rev=1.1&view=markup

I haven’t attempted statically linking in SDL yet, so I can’t answer
your question, but I’d be interested in the answer too.

Usual disclaimers about static linking SDL; on Windows, you can supply a
dynamically linked version on demand, but don’t have to ship it with the
final package (the LGPL only requires you to hand it over if asked,
which in reality…no one ever does. :slight_smile: ). This is useful when you’re
trying to keep the package small and sane.

PhysicsFS is under the zlib license, which means you can statically link
it, modified or otherwise.

–ryan.

Since this comes up on the SDL mailing list a lot, I should probably
say:

There’s a seperate mailing list for PhysicsFS discussion, development
and support.

Send a blank email to physfs-subscribe at icculus.org to get on the list.
It’s been very low-traffic since we hit a stable 1.0 release.

It’s better to ask questions there than on this mailing list, out of
respect to people on this list who aren’t using physfs.

Thanks,
–ryan.