You have to compile on each platform, many guys distribute the source, but for mac you can get into a mac and compile there and release the binary, for linux you can do so but it may not work on many linux versions

executables are always only useable on one OS. (exceptions are emulators like, i think, Wine for linux and similar tools)

so, either get a "cross-compiler" that will create an executable able to run on its target-OS, or compile it on the other OS with an appropriate complier.

Wow, this all seems so confusing... I think I'm just going to stick with DirectX for now. Thanks for the help though!

How is this confusing? It is really simple:

1) Link your app to the dynamic SDL library (in other words, use the DLL)
2) Zip up the source code of SDL only (not your code) and include it with your distribution
3) Include the LGPL license (there are text and html versions on the LGPL site for use)
4) Create a copyright notice in a README file that says something like "This program uses SDL version x.x and is included in a zip archive blah blah blah..."
5) Distribute your app. Done. Stop worrying.

I was refering to cross-platform programming. Anyway, when you say "include the LGPL", does that mean my entrie program has to comply with the LGPL, or just the SDL code?

Quote:Original post by programwizard
I was refering to cross-platform programming.

Cross-platform programming means that the source code can be compiled for various systems. If you use DirectX in your program, you won't be able to compile to produce a Linux binary. But if you use SDL, you will be able to, without changing your code any further.

The source code, compiled with a Windows compiler, will produce a Windows executable that runs on Windows.
The source code, compiled with a Linux compiler, will produce a Linux executable that runs on Linux.
The source code, compiled with a MacOS compiler, will produce a MacOS executable that runs on MacOS.

There are some compilers that are designed to run under one operating system but to produce executables for a different system (e.g. compile GCC under Windows, it'll run under Windows, but still produce Linux binaries). Those are cross-compilers.

The SDL enables you to write cross-platform code because they went to the trouble of implementing its functions for each supported platform. That is, while your program is just using SDL routines, the SDL routines themselves have been written to use the Windows API or the Linux API, depending on the platform you compiled SDL for (or which binaries you grabbed). This means that your code doesn't contain any platform-specific code (all of it is in the SDL binaries), which enables you to compile it on multiple platforms - so long as you link with the appropriate version of the SDL libraries.

Quote: Anyway, when you say "include the LGPL", does that mean my entrie program has to comply with the LGPL, or just the SDL code?

When writing your program, you have to comply with the LGPL, meaning that you must enable end-users to replace any LGPL component you used. You are still free to license the rest of your program however you want.

How far you need to go to comply with the LGPL depends on how you use the LGPLed components.
If they are in DLLs, all you need to do to replace the component is to put in a different DLL, so the only code you need to provide is the code for the DLL. If you haven't modified it, it is relatively painless. If you have modified it, you must make the source code for the modified version available.
If you statically linked with the components, replacing them requires relinking the whole application. You must then, in addition to the LGPLed components themselves, either provide the source code for your application (so that it can be compiled and linked) or the object files (post-compilation, pre-linking) for each platform you distribute your application for (i.e. if you have a Windows version, you must provide the Windows object files, etc)

By far the simplest is to dynamically link to the SDL. The LGPL notice you need to include with your application only concerns the SDL components, not the rest of the application.

OK, I think I get everything now:
-If I write my code in SDL, all I have to do is compile it on another OS that has SDL and it will work on that OS.
-The only thing I have to distribute with my app is the SDL source code and the LGPL notice. Other than that, I can keep everything and put it under whatever license I want.

Quote:Original post by programwizard
OK, I think I get everything now:
-If I write my code in SDL, all I have to do is compile it on another OS that has SDL and it will work on that OS.
-The only thing I have to distribute with my app is the SDL source code and the LGPL notice. Other than that, I can keep everything and put it under whatever license I want.

You don't even need to distribute the SDL source code with your app, you just need to make it available. It can be a link back to the SDL site from a page on your website or whatever. (Again, provided you don't modify the original SDL codebase).

The LGPL seems convoluted to the beginner and there's a LOT of dis-information floating around the internet.

Commercial apps CAN use LGPL software and charge money for it, without releasing the source code of their own apps as long as they don't mod the LGPL'd code they base their work on.

Lots of commercial games use SDL. I think America's Army does, as does Gish and tons of other Indie game projects.

Does SDL even have a governing body that could pursue a license infraction? Last I recall, the project was originated and administered by Loki Games, which is now deader than Colonel Sanders.

Not that I'm encouraging people to break the license, but is there anyone who could claim enough ownership of SDL to enforce its LGPL?