The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I encounter an error when statically linking SDL2 in my application with Visual 2012.
I built SDL2 from latest repository, using the Visual 2012 project provided, with modifications so that it builds as a static lib with static VC runtime.

The application builds, but at execution it crashes with "application.exe has triggered a breakpoint."
According to Visual debugger, this happens line 98 in SDL_stdlib.c: (the line after _chktsk() below)


I can build SDL2 as dynamic dll or static dll, and in both cases my application is working.

If I build with SDL2 static lib, but with Runtime Library 'Multi-threaded debug' instead of 'Multi-threaded', my application works.

I added dependencies to winmm.lib, imm32.lib, version.lib as explained here.
I tried to exclude LIBCMT as advised here, but then I get a bunch of unresolved externals.

My application is just an SDL initialization and exit:



Any tips to investigate further would be great

Are you using Visual Studio 2012 for a Store application, or Desktop application?


On Sat, Mar 30, 2013 at 10:08 AM, li wrote:

A Desktop application.

What were your unresolved external functions?


On Sun, Mar 31, 2013 at 2:42 AM, li wrote:

That's a list of __security_cookie, something like:

I tried to follow the information found here, and it seems that can I solve this error by either adding a dependency to bufferoverflowU.lib, or disabling Security Check in project options (flag /GS-).
In both cases, I get the following error when building:

In both cases though, I can still build and successfully run if I use a 'Multi-threaded debug' Runtime Library instead of 'Multi-threaded'.

Is your project a win32 console or a windows form project?  You may have to tell the compiler it is a windows/form project in your project settings if you specified that it's a console project.


On Sun, Mar 31, 2013 at 10:21 AM, li wrote:

You mean the flag /SUBSYSTEM:WINDOWS, right?
This is the case already.

I don't have access to VS2012 anymore, so I'm sort of running out of ideas - anyone else with VS2012?  I can't say I ever ran into any sort of CRTStartup problem when I tried compiling and linking to SDL2 apps.

Sorry I can't be of any more help








On Mon, Apr 1, 2013 at 9:09 AM, li wrote:

Can you post your modified .vcxproj file somewhere so one can try to repro this?

If VS11 access is the only problem ... a free download of the Express version is here:
http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-for-windows-desktop

On 4/1/2013 6:56 AM, Alex Barry wrote:

I uploaded my application project (Game.vcxproj) and SDL project (SDL_VS2012.vcxproj) here: http://www.files.com/set/5159b39a5e530

Except that I put the wrong file in the zip.
So here are the right ones
- SDLText.vcxproj for my project
- SDL_VS2012.vcxproj for SDL2; here the configuration 'Release lib static' is the right one
http://www.files.com/set/5159b4ef6010f

Back to this topic with some results that are hopefully interesting..

I managed to build everything I need statically (SDL, SDL_image, SDL_ttf.)

I found three ways to get rid of the unresolved symbol _WinMainCRTStartup; in all cases I build with /NODEFAULTLIB, so that I know which are the actual dependencies.

Solution 1) Dependency on msvcrt.lib; this works well, but my application gets a dependency on msvcr110.dll, which I clearly don't want (it would require to bundle MS VC11 redist or the dll file.)

Solution 2) Dependency on libcmt.lib; that's what I settled with for now (no extra Windows dll dependency.)
However, I have to remove the _chktsk function from SDL_stdlib.c (lines 95-99), otherwise the application crashes on startup.
I also have to remove the declaration of _fltused in SDL_stdlib.c (line 53) if I use SDL_image, otherwise build fails with LNK2005: __fltused already defined.

Solution 3) No dependency on msvcrt.lib and libcmt.lib, but define SDL_main as entry point for the application.
Actually I cannot build my application like this, but it works for a minimalist application, only linking with SDL.lib, drawing a rectangle.

So I wonder, do I need a dependency on Visual C runtime? If yes, my understanding is that SDL_stdlib.c is not compatible with static VC runtime, but only with msvcrxx.dll.

Just to confirm: you're trying to link EVERYTHING statically, so that
it is bundled into the same actual executable file as your program,
right? Bear in mind that if you have a properly designed installer
application, then the only place you should WANT to do this is in the
actual installer itself. You might want to stick all of the dll files
into the same directory as your actual program so that it'll give them
preferential treatment, and so they won't be deleted by something else
uninstalling itself, but as a general rule of thumb you usually DO
want to use dynamic linking for some things (particularly SDL and your
language runtime), so that you can just distribute those when you want
to provide improvements, instead of distributing your entire program.

Certainly, there are places where I would consider purely static
linking good, but they basically consist of installers and core system
components, and then mostly to reduce the chances of breaking your
system by overwriting something important. For ordinary applications
AND ordinary system components, I would use at least the msvcrt dll.


Go and check the redistribution terms for msvcrt*.dll (might be here:
http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.80%29.aspx).
If the redistribution terms are acceptable for your usage, then I'd
suggest shipping it with your executable. There are other ways to deal
with the need for an entry point, but you don't really want to deal
with that, and it actually DOESN'T improve things for the most part.


Are you certain about the spelling? Google only seems to know of
_chkstk. What does it tell you about the crash?


_fltused seems to trigger inclusion of floating-point code. Probably
another case of shooting yourself in the foot by using all-static
linking. However, you might try to alter how, exactly, you do your
linking in order to deal with this. In particular, see if moving all
linkage to libcmt.lib & co. to a linking stage AFTER you link the
libraries & your code helps.


As a general rule of thumb, and C program on the Windows platform does
require one or another of the Microsoft Visual C runtimes. In fact,
even Mingw/MSys use it (not so certain about Cygwin). Here's a link
that's relevant to this issue:
http://stackoverflow.com/questions/9052694/visual-studio-2010-msvcr-dependency-removal
. In essence, the Visual C runtime implements the actual support for C
in Windows. You might not be able to build your application without
the runtime, but I'm surprised that you were able to get your
rectangle-drawer working without it, since the runtime actually calls
the main (or WinMain!) function.

Now, I said earlier that there are ways other than what you did to
deal with the entry-point, and indeed there are. In fact, this is also
true of the runtime. There are basically four "common" runtime
environments on the Windows platform (and five if you count Windows
: Win32 (by far the most common), Interix (or something like that,
it's a Posix emulation layer), .NET, and Native. These are what actual
programs perceive as the OS. The Microsoft Visual C runtime is not
party of any of these environments, which implies that you can do
without it: and indeed, you can. In fact, there's currently a project
to create an open-source alternative, and if you're one of the handful
of Windows assembly programmers then you might not use a runtime at
all. However, if you're using anything other than C, that really just
means that you have to implement all of that functionality yourself.
This is NOT something that application developers should be doing,
this is a job for COMPILER DEVELOPERS.

In short: make an exception to your static-linking for the Microsoft
Visual C runtime, static linking to that is almost guaranteed to be
more trouble than it's worth.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yes, I'm trying to build a one file application.
I understand that I can provide an installer, which will contain all the dlls required, but that's not what I'm trying to do.
I also understand that SDL2 "zlib" license allows me to do so, which is why I insist on it :)


msvcrxx.dll sounds pretty horrible. I can bundle msvcr110.dll, I guess Microsoft allows it, but I don't want any dll from the start; counting on msvcrxx.dll on the target system would probably work, but then I have to choose a version (say msvcr80.dll), but if I can build without this kind of dependency it's even better.
The link you provide mentions about the /clr switch, I looked at it suspiciously so far, but I will try to look at it more closely.


You're right, it's _chkstk. The crash is the one I described in the initial post: "application.exe has triggered a breakpoint."


That would be due to mis-configuration of my libs and not conflict with libcmt.lib then, I will try to dig this further, I don't want to remove floating-point support :D


Yes, it works, which is why I was thinking that I could get entirely rid of VC runtime.
It's not working well though, I forgot to mention it, the application is not closing properly, the process is still running after 'exit', even though the window is closed.

So I have to work on this /clr switch, and on libs configuration to restore _fltused.
And I understand that I should keep VC runtime; my code is C++ and I rely comfortably on STL; STL requires libcpmt.lib, which in turn is extremely likely to require VC runtime.

I still want - if possible - libcmt.lib and not msvcrt.lib, so any hint on the _chkstk issue would be appreciated..

SDL does not attempt to replace the C runtime. You need to link to the Visual C++ runtime (which includes both the security cookie and _WinMainCRTStartup)!

All that SDL_stdinc.* does is implement needed standard C types/functions that are missing from some C/C++ runtimes. When the C/C++ runtime does include these functions, SDL's implementations default to the C/C++ runtime's implementations.

If you're truly insistent on ditching MSVCrt, however, you could always disable just about every default compiler option and use Matt Pietrick's libctiny (I hope you're ready to fix dinosaur code issues, though) or Google's minicrt (if that's even still floating around, I can't seem to find the source code or even a download with Google lol), or you could always go through the "fun" of implementing your own CRT.

As it happens, MSVCRT source code is supposed to be included with Visual C++, so you actually have a first-hand reference to how to implement a Visual C++-compatible CRT if you wanted to (and yes, you can totally statically link it).

I've run into the chkstk assertion when I allocate more than 4k in a stack frame.  If you're allocating that much, I would recommend using SDL_stack_alloc() / SDL_stack_free() or dynamically allocating the data you need.


On Sat, Mar 30, 2013 at 7:08 AM, li wrote:

Ok, but what is your actual reason for WANTING to statically link
everything? When I went through this stage it was partially because I
didn't want to worry about redistibution rules, and partially because
I wanted things to be "nuke proof". I actually have some ideas on how
I could still pull off that last bit, though I haven't spent the time
and effort yet. What's YOUR reason?


Just for reference, you do know that every Windows application,
including those that actually implement the Win32 api, all have to
perform a load-time (aka not statically linked) access to nt.dll,
right? The kernel interface isn't reliable, so ALL kernel calls go
through that dll, where they then get translated into calls to the
kernel itself. This is even true of the Native API, and the native api
is used to implement all of the OTHER apis.

If you're opposed to using nt.dll... well, in that case you've gone
off the deep end. It is part of the (poorly) DEFINED way that Windows
applications ARE to follow when interacting with the operating system.
This is used by basically everything that doesn't get compiled with
the kernel itself, and is basically a "THOU SHALT" sort of thing. I
haven't seen anything in this conversation that I've been convinced
was actually related to SDL, but this one I won't even try to help you
with, we're not talking about DOS or bare-metal here.


The C runtime dlls aren't distributed with Windows itself. If the user
has already installed another program then you're HOPEFULLY safe, but
if they haven't (let's say they've gotten a new system, and your
program is the first one they want to use on the new install) then
you're likely to get some confused bug reports. Thus, you really do
want to distribute them if you're using them.


/clr is for programs that either use, or interact with, the .NET
runtime, such as those written partially or entirely in C#. It's very
likely that you DON'T want it.


That sounds like you have debugging enabled? I don't use MS Visual
Studio so I won't be much help on this, but if you list your compiler
& similar settings then someone else might be able to point out where
you're running into problems (a small program, much like your "draw
rectangle" program, that runs into the same problem would be even
better).


I don't blame you, I consider floating-point important for most modern
applications myself. Bear in mind that so far, what I've noticed (I
only started paying attention with your previous message, mind you)
all sounds to me like some form or another of configuration (or maybe
code...) problem. If you can get a code sample (like the one I
suggested above) that supports all of the features that you want but
WORKS, then you'll have a pretty good hint that the problem is either
in your configuration, or your code (or both! that can happen too). If
you CAN get such a working proof-of-concept then I suggest abandoning
your current attempt, making a duplicate of the successful demo, and
reimplementing on top of that. A few months ago I was working on the
formatting of a web page, and that kind of reimplementing-from-scratch
technique was the only thing that got it to do what I thought it was
already supposed to be doing.


It might not actually be running after that. I haven't attempted to
implement a Windows C Run-time myself, but I think the OS expects some
sort of call from the application when it's exiting.


Oh very much so. In fact, with MSVC++ I'd say that doing without the
runtime is even more of a bad idea. For some references on what you'd
have to do THEN, start reading this
(http://wiki.osdev.org/C%2B%2B_Bare_Bones#C.2B.2B_specifics) page at
the section linked, then skip down to the "kmain.cpp" and read from
AFTER the code and command-line examples, to where the "linker.ld"
section begins (incidentally, you might find some command-line
switches with interesting Visual C++ versions). Also read this:
(http://wiki.osdev.org/C%2B%2B), which you might as well read all the
way to the end (bear in minds that the STL sort-of is part of the
language specification, and that "STL" is actually an unofficial name
that all reasonable people are simply okay with, rather than being
official). This is also relevant:
http://stackoverflow.com/questions/2782915/what-should-i-know-about-structured-exceptions-seh-in-c
.

All in all, I'd say those three links should provide all of the
information needed to weasel out of implementing the C & C++ runtime
libraries if you ever have a boss that wants you to do it . In
fact, the very fact that two of those links are to a site dedicated to
writing Operating Systems should be enough to pull off the trick .

However, just in case you're actually interested AFTER looking through
those links, despite not being interested BEFORE, there probably are
some zlib (or similar) licensed C & C++ standard libraries available
that can be adapted to Windows by just changing out OS calls.
Particularly with the STL, I think that you'd only have to worry about
allocation/deallocation, RTTI, and exceptions. I don't know how the
Microsoft implementation does those, but I do half-remember running
across relevant information online. I strongly recommend against this,
but it can be done.


I don't recall the problem itself, but if the symbol wasn't found then
you can implement it yourself, link:
http://stackoverflow.com/questions/8400118/what-is-the-purpose-of-the-chkstk-function
. If your getting some sort of fault triggered by _chkstk then it's
most likely an access violation, cause by trying to use more stack
space than your program is ALLOWED to have. The three most likely
reasons for this are:
1) You allocated so much memory on the stack, either in huge objects
or via a long function-call cascade, that you honest-to-goodness ran
out. I kid ye not, I HAVE ACTUALLY DONE THIS, specifically in an
STL-based game-map system (I believe that it was 3-d too, though it's
been quite a while);
2) You have an infinite loop. I think that everyone does this at least
once, which is why most of us consider fiddling with operating systems
high-level work, and memory-protection is so common; and
3) You reduced the stack allocation for your application below some
reasonable level. If this is what you did then you should have a
REALLY
good reason for both using SDL, AND aiming for extremely
memory-constrained systems.


Now, here's what I think is going on, and please correct me if I'm
wrong: you're wanting to write a plain, no-frills application, no
fancy glitter or anything else, and thus you've been lead to not using
dlls because they're "fancy", and to reducing the stack size because a
big stack is inherently heavier than a small one (remember, I've gone
down the path I'm describing myself). It's straight-forward and
logical, but at the same time it's NORMALLY a bad idea. I recommend
that unless you're interested in running into lots of headaches (or,
alternatively, implementing a programming language) that you just use
the mscvrt dlls, and distribute them with your program. You can do
this by writing a small helper/launcher program that looks around for
the dlls, writes some copies that are EMBEDDED INTO IT out to disk if
it doesn't find them (this is very easy to do, and only requires some
command-line programs), and then starts the real program, all using
only Win32 functions. It won't be cross-platform, but it will be very
EASY to MAKE cross platform, since only a handful of basic functions
are required. I've even scratched out concepts of the bits other than
the helper/launcher, and THOSE can be used to embed any data files
into any non-final executable for any platform without even having to
port them.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I'm actually doing something similar: writing a C-style
virtual-function interface for part of the C runtime! Admittedly my
goal is "constrained", but said goal is to write a printf
implementation that will send it's output to an arbitrary character
stream interface, while being compatible with completely arbitrary
character encodings (including with variable widths, alignment
multiples other than the actual size of a character, and offsets from
those alignments), including "characters" that are actually e.g. C++
classes, so it's insane in it's own way.

A decent portion of the old portion of the C standard library is
fairly simple and straight forward, but setjump/longjmp require
assembly, and various other problems come up as well, and that's not
even considering issues like C++'s exceptions, and run-time type
information, where I've gotten the impression that they might actually
vary with the compiler flags. These are dark and dangerous waters.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Trust me, I know, I'm implementing my own C runtime right now. Basic C++ support is important (in fact, I just finished getting MinGW static global C++ constructors and destructors to work), but I never use exceptions so that will probably be the last thing I make work (especially since MinGW and Visual C++ do it completely differently (and in fact MinGW can do it two different ways), and this means massive bloat in my runtime to implement it both ways...)
As for setjmp/longjmp; you make it sound like capturing the current context and resetting it later is difficult.

That's very clear, thanks.
I do not want to get rid of VC runtime if it's not supported by SDL.
I do want to get the static VC runtime (libcmt.lib) instead of the dynamic VC runtime (msvcrt.lib) though.


I am not allocating anything. The application crashes before my main is called, unless I remove _chkstk in SDL_stdlib.c. It seems that libcmt.lib does not want anyone else to declare _chkstk.


I want a single file executable. I think that it's the ideal way to distribute a very small game.

Don't get me wrong, I have nothing against VC runtime.
I absolutely don't want to implement a runtime by myself, but I want to use the static runtime provided by Microsoft (libcmt.lib), which is a method supported by Microsoft.
You can see that in the first chart in the link sent by Jared: http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.80%29.aspx

My understanding is that SDL_stdlib.c and libcmt.lib conflict with each other.
You can find a reproduction solution - VS 2012 - here: http://www.files.com/set/517a947761bda
It contains three configurations:
- 'Libcmt with _chkstk' > produces the error
- 'Libcmt without _chkstk' > no error
- 'Msvcrt' > no error
(includes and libs are in the solution, so it should build straighforwardly)

Regarding the two other topics we discussed yesterday:
- Yes, I don't want CLR, I read the microsoft MSDN page too quick yesterday
- When linking SDL_image, I still get the _fltused conflict (between SDL_stdlib.c and libcmt.lib) even though I link everything at the very last step. I don't want to make this thread too complex, so maybe we can let it aside for now, but I can setup a reproduction solution if you wish.

Actually, it might be useful to implement a C runtime that provides the bare minimum to implement SDL.
But, this is a project for another time, and maybe another programmer. I'm just trying to figure out how the CRT actually does stuff over here, and I'm already beating my head against the wall. Dx

Considering SDL relies heavily on an OS to do stuff anyway (video,
audio, input, etc.) there isn't much point in doing that when you're
pretty much guaranteed to have a proper C runtime in such a situation.

2013/4/26, Nathaniel J Fries:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Actually, I think that Visual C++ does it two ways too, and maybe one
of those is compatible with the G++ way.


I was thinking more "if you do it wrong, things will explode", but it
WAS my first stab at it, and I was actually doing it as part of a
"Continuations for C" concept, and I was extending it with functions
to register destructors, and I basically never work in assembly, etc.,
so there was a lot of blind fumbling while I tried to figure out what
info to look for.

Incidentally, if you feel up to taking a stab at continuations then I
do suggest inserting stubs at a very early stage. You might not flesh
them out for some time, but at least it would always keep them in the
back of your mind.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

There actually is a reason to do this. On Windows an application and
the libraries that it uses can each use a different C runtime. Not
only are there the open-source ones, but Microsoft itself has several
variants out there. The result of this is that you cannot safely
allocate memory in the code of one executable, and deallocate it in
another. By simply providing a malloc/realloc/free implementation in
SDL2 this headache could be greatly reduced (though if you somehow
included SDL2 repeatedly, and I'm thinking of the old requests to
provide a SDL interface for the NPAPI here, then this could require a
bit more work to achieve true "universalism").
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It's not about lacking a proper C runtime.

One reason is what Jarod said:


Another reason is the issue the OP is facing.

Yet another reason is the original purpose of libctiny, which is to not bring the bloat of MSVCRT to all applications using SDL.

You could also use it to implement a main() that takes argv as UTF-8 instead of in a codepage or wide character (although SDL2_main could accomplish this instead).

And let's say you're a C purist (I've seen a few on here before). Maybe you don't need all those functions required to support C++ exceptions, RTTI, static constructors and destructors, or even name demangling (MSVCRT includes a function, _unDNameEx, which is quite large; and G++ has abi::__cxa_demangle which is similarly large). This can trim down the size of an executable considerably!

Anyway, this is all irrelevant. If someone really wants it bad enough, they'll do it themselves, and then hopefully they'll be kind enough to share.

Actually, if it's all about the memory managers, whatever program you're using SDL in is going to have its own malloc anyway. (Assuming you're writing from a native code language, at least.) Why not have a SDL_RegisterMemoryManager() function, where you pass in a set of function pointers, for malloc, realloc, and free?


This would certainly be useful to me, since I use SDL with Delphi code and Delphi's memory manager has a bunch of useful debug features (leak tracing, corruption guards, etc) that most memory managers don't come with. If I could extend that into SDL it would be awesome. :)


Mason



From: Nathaniel J Fries
To:
Sent: Friday, April 26, 2013 12:51 PM
Subject: Re: [SDL] Link SDL2 statically with Visual C++ 2012



Sik wrote: Considering SDL relies heavily on an OS to do stuff anyway (video,
audio, input, etc.) there isn't much point in doing that when you're
pretty much guaranteed to have a proper C runtime in such a situation.


It's not about lacking a proper C runtime.

One reason is what Jarod said:







Quote: There actually is a reason to do this. On Windows an application and
the libraries that it uses can each use a different C runtime... By simply providing a malloc/realloc/free implementation in
SDL2 this headache could be greatly reduced


Another reason is the issue the OP is facing.

Yet another reason is the original purpose of libctiny, which is to not bring the bloat of MSVCRT to all applications using SDL.

You could also use it to implement a main() that takes argv as UTF-8 instead of in a codepage or wide character (although SDL2_main could accomplish this instead).

And let's say you're a C purist (I've seen a few on here before). Maybe you don't need all those functions required to support C++ exceptions, RTTI, static constructors and destructors, or even name demangling (MSVCRT includes a function, _unDNameEx, which is quite large; and G++ has abi::__cxa_demangle which is similarly large). This can trim down the size of an executable considerably!

Anyway, this is all irrelevant. If someone really wants it bad enough, they'll do it themselves, and then hopefully they'll be kind enough to share.



Nate Fries



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Oops. Too used to text editors. Let's try that again:

That is a good idea. Perhaps something like this:

/* Arbitrary .c file */
static void *malloc_data = (void*)( &malloc ),
*realloc_data = (void*)( &realloc ),
*free_data = (void*)( &free );
static void* (*malloc_function)( void* /* Data */, size_t ) = SDL_mallocwrapper;
static void* (*realloc_function)( void* /* Data */, void*, size_t ) =
SDL_reallocwrapper;
static void (*free_function)( void* /* Data */, void* ) = SDL_freewrapper;

void* SDL_mallocwrapper( void *data, size_t size )
{
if( data )
{ return( ( ( void* (*)( size_t ) )data )( size ) ); }
return( 0 );
}
void* SDL_reallocwrapper( void *data, void* mem, size_t size )
{
if( data )
{ return( ( ( void* (*)( void*, size_t ) )data )( mem, size ) ); }
return( 0 );
}
void SDL_freewrapper( void *data, void* mem )
{
if( data )
{ ( ( void (*)( void* ) )data )( mem ); }
return( 0 );
}

void* SDL_malloc( size_t size )
{
if( malloc_function )
{ return( malloc_function( malloc_data, size ) ); }
return( 0 );
}
void* SDL_realloc( void *old, size_t size )
{
if( realloc_function )
{ return( realloc_function( realloc_data, old, size ) ); }
return( 0 );
}
void SDL_free( void *mem )
{
if( free_function )
{ free_function( free_data, mem ); }
}

void SDL_SetAllocators
(
void *maldata, void* (*malfun)( void*, size_t ),
void *redata, void* (*refun)( void*, void*, size_t ),
void *fredata, void (*frefun)( void*, void* )
)
{
malloc_data = maldata; malloc_function = malfun;
realloc_data = redata; realloc_function = refun;
free_data = fredata; free_function = frefun;
}

/* End of code. */


Not the prettiest code in the world, but effective. Thoughts?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org