Dynamically loading SDL dlls

Jeremy · October 30, 2007, 4:23am

Is there an alternative to SDL_SetLibraryPath ?

I’d like to load the SDL libraries from a folder of my choice, one that
isn’t the executables folder, and isn’t in the path. Is there no support for
doing this? Some documentation implies the dll shouldn’t be loaded/required
until you call SDL_Init, but without the dll in the path, windows folder,
app folder, etc. My dll that uses SDL fails to load, which indicates it does
indeed need the sdl library well before SDL_Init. SDL_SetLibraryPath appears
to be what I would use in this case but it seems to have been removed some
time ago.

Any alternatives?

Jeremy

Ulrich_Eckhardt · October 30, 2007, 6:24am

Is there an alternative to SDL_SetLibraryPath ?

Not 100% sure, as I couldn’t find any documentation on what it should do.

I’d like to load the SDL libraries from a folder of my choice, one that
isn’t the executables folder, and isn’t in the path. Is there no support
for doing this? Some documentation implies the dll shouldn’t be
loaded/required until you call SDL_Init, but without the dll in the path,
windows folder, app folder, etc. My dll that uses SDL fails to load, which
indicates it does indeed need the sdl library well before SDL_Init.
SDL_SetLibraryPath appears to be what I would use in this case but it seems
to have been removed some time ago.

You need to treat SDL as a plugin then. IOW, for win32, take a look at
LoadLibrary/GetProcAddress while for POSIX look at dlopen/dlsym.

Other than that, how about replacing the application with a simple script that
sets up the environment and then launches the executable?

UliOn Tuesday 30 October 2007 05:23:23 Jeremy wrote:

Michael_Parker · October 30, 2007, 6:57am

Is there an alternative to SDL_SetLibraryPath ?

I’d like to load the SDL libraries from a folder of my choice, one that
isn’t the executables folder, and isn’t in the path. Is there no support for
doing this? Some documentation implies the dll shouldn’t be loaded/required
until you call SDL_Init, but without the dll in the path, windows folder,
app folder, etc. My dll that uses SDL fails to load, which indicates it does
indeed need the sdl library well before SDL_Init. SDL_SetLibraryPath appears
to be what I would use in this case but it seems to have been removed some
time ago.

If your dll is failing to load, that tells me that you are linking with the
import library still. When you want to load another dll manually, you can’t
link to the import library. Otherwise, Windows will attempt to load the dll
from the usual locations and fail if it can’t find it.

Any alternatives?

If you’re going to pursue this, you’ll have to use the
LoadLibrary/GetProcAddress routines on Windows, and libdl or whatever is
appropriate on other platforms. It also means that you’ll have to convert
all of the function declarations in the SDL headers into function pointer
declarations and then load each of them one at a time. So you’d get
something like this:

// in header
typedef int (*pfSDL_Init)(Uint32);

pfSDL_Init SDL_Init;

// in source (for Windows)
static HMODULE s_sdlLib = 0;

void loadSDL()
{
s_sdlLib = LoadLibrary(“SDL.dll”);
if(!s_sdlLib) …

SDL_Init = (pfSDL_Init)GetProcAddress(s_sdlLib, "SDL_Init");
if(!SDL_Init) ...

// repeat for each function in the library

…
}On 10/30/07, Jeremy wrote:

–
Mike Parker

Andre_Krause · October 30, 2007, 10:09am

Michael Parker wrote:

Is there an alternative to SDL_SetLibraryPath ?

I'd like to load the SDL libraries from a folder of my choice, one
that isn't the executables folder, and isn't in the path. Is there
no support for doing this? Some documentation implies the dll
shouldn't be loaded/required until you call SDL_Init, but without
the dll in the path, windows folder, app folder, etc. My dll that
uses SDL fails to load, which indicates it does indeed need the sdl
library well before SDL_Init. SDL_SetLibraryPath appears to be what
I would use in this case but it seems to have been removed some time
ago. 
If your dll is failing to load, that tells me that you are linking with
the import library still. When you want to load another dll manually,
you can’t link to the import library. Otherwise, Windows will attempt to
load the dll from the usual locations and fail if it can’t find it.
Any alternatives?
If you’re going to pursue this, you’ll have to use the
LoadLibrary/GetProcAddress routines on Windows, and libdl or whatever is
appropriate on other platforms. It also means that you’ll have to
convert all of the function declarations in the SDL headers into
function pointer declarations and then load each of them one at a time.
So you’d get something like this:

// in header
typedef int (*pfSDL_Init)(Uint32);

pfSDL_Init SDL_Init;

// in source (for Windows)
static HMODULE s_sdlLib = 0;

void loadSDL()
{
s_sdlLib = LoadLibrary("SDL.dll ");
if(!s_sdlLib) …
SDL_Init = (pfSDL_Init)GetProcAddress(s_sdlLib, "SDL_Init");
if(!SDL_Init) ...

// repeat for each function in the library
…
}

what Mike says is so true… and so painful.
imho this renders the dll concept inappropriate
for some special cases - like loading a dll from a
memory place (there are solutions, but they are even worse)
or from a resource archive or just some arbitrary subdirectory.

i suggest you to statically link libSDL (and as much
other libs as you can), this saves you from a lot
of trouble.> On 10/30/07, Jeremy <jswigart at gmail.com <mailto:jswigart at gmail.com>> wrote:

–
Mike Parker

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jeremy · October 30, 2007, 1:43pm

Ug. If I I really don’t want to get into the whole mess of providing object
files and such to comply with the license if I start static linking stuff.
All I ultimately need is more control over where it loads from. Sounds like
that’s not supported ‘out of the box’ so I’ll have to convert the headers
and load things dynamically.

Hoped there was a built in way to accomplish this, as the comments for
SDL_Init explicitly state that the dll should be loaded as part of that
function. After looking at the actual source its clear that isn’t the case
at all.

From what little documentation I could find, it appears once upon a time the
SDL_SetLibraryPath() was available that supported dynamic loading from a
specified location. I don’t know why it was deemed a good idea to remove
that, as it would be very useful at this point.

JOn 10/30/07, Andre Krause wrote:

Michael Parker wrote:
On 10/30/07, Jeremy <@Jeremy mailto:Jeremy> wrote:
Is there an alternative to SDL_SetLibraryPath ?

I'd like to load the SDL libraries from a folder of my choice, one
that isn't the executables folder, and isn't in the path. Is there
no support for doing this? Some documentation implies the dll
shouldn't be loaded/required until you call SDL_Init, but without
the dll in the path, windows folder, app folder, etc. My dll that
uses SDL fails to load, which indicates it does indeed need the sdl
library well before SDL_Init. SDL_SetLibraryPath appears to be what
I would use in this case but it seems to have been removed some time
ago.
If your dll is failing to load, that tells me that you are linking with
the import library still. When you want to load another dll manually,
you can’t link to the import library. Otherwise, Windows will attempt to
load the dll from the usual locations and fail if it can’t find it.
Any alternatives?
If you’re going to pursue this, you’ll have to use the
LoadLibrary/GetProcAddress routines on Windows, and libdl or whatever is
appropriate on other platforms. It also means that you’ll have to
convert all of the function declarations in the SDL headers into
function pointer declarations and then load each of them one at a time.
So you’d get something like this:

// in header
typedef int (*pfSDL_Init)(Uint32);

pfSDL_Init SDL_Init;

// in source (for Windows)
static HMODULE s_sdlLib = 0;

void loadSDL()
{
s_sdlLib = LoadLibrary("SDL.dll ");
if(!s_sdlLib) …
SDL_Init = (pfSDL_Init)GetProcAddress(s_sdlLib, "SDL_Init");
if(!SDL_Init) ...

// repeat for each function in the library
…
}
what Mike says is so true… and so painful.
imho this renders the dll concept inappropriate
for some special cases - like loading a dll from a
memory place (there are solutions, but they are even worse)
or from a resource archive or just some arbitrary subdirectory.

i suggest you to statically link libSDL (and as much
other libs as you can), this saves you from a lot
of trouble.

–
Mike Parker

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Andre_de_Leiradella · October 31, 2007, 12:49am

Well, according to the Windows API, DLLs are loaded from:

The directory from which the application loaded;
The current directory;
The Windows system directory (usually system32);
16-bit system directory (system);
Windows directory (GetWindowsDirectory returns this folder); and
Directories listed in the PATH environment variable.

You can try item #6 to make Windows find the DLLs in the folder you want
by appending it to the PATH variable. You can make this from within your
application.

Cheers,

Andre> Is there an alternative to SDL_SetLibraryPath ?

I’d like to load the SDL libraries from a folder of my choice, one that
isn’t the executables folder, and isn’t in the path. Is there no support for
doing this? Some documentation implies the dll shouldn’t be loaded/required
until you call SDL_Init, but without the dll in the path, windows folder,
app folder, etc. My dll that uses SDL fails to load, which indicates it does
indeed need the sdl library well before SDL_Init. SDL_SetLibraryPath appears
to be what I would use in this case but it seems to have been removed some
time ago.

Any alternatives?

Jeremy

icculus · October 31, 2007, 9:02am

From what little documentation I could find, it appears once upon a
time the SDL_SetLibraryPath() was available that supported dynamic
loading from a specified location. I don’t know why it was deemed a good
idea to remove that, as it would be very useful at this point.

I had never even heard of SDL_SetLibraryPath before you mentioned it
here, which means it’s been gone for a long, long time.

I could provide several guesses as to why it was removed, but it’s not
really relevant, as you’ve seen that SDL_Init relies on the .DLL already
being loaded as it is part of the .DLL anyhow.

Can you explain why SDL.dll needs to exist in a different location than
the executable? You are asking how to accomplish something very
specific, but I have a feeling that understanding the overall goal might
be more useful to finding a solution that works for you.

–ryan.

Andre_Krause · October 31, 2007, 1:08pm

Can you explain why SDL.dll needs to exist in a different location than
the executable? You are asking how to accomplish something very
specific, but I have a feeling that understanding the overall goal might
be more useful to finding a solution that works for you.

–ryan.

i have a similar desire, so i just answer before jeremy:

its a specific problem, yes, but it is rather a problem of bad support by the
operating system. afaik windows seems to know only one way of dynamically
loading a library (LoadLibrary from a file) - and thats very limited. what about
loading dlls from a resource? what about loading dlls over the internet to a
memory buffer and starting the dll from that place? why is such basic stuff not
supported directly by some standard system library?

and its not hard to understand why one needs that. if you want to have an
install-free application, you just want to carry all your dll’s as a resource
with your executable. happily, my own little project is open source, so i have
no problem with static linkage, and do not to do nasty unportable dll stuff.

necron · October 31, 2007, 1:23pm

“if you want to have an
install-free application, you just want to carry all your dll’s as a resource
with your executable.”

That’s how it is anyway. Just have the dll in the folder that the exe is in.

As for loading a dll off of the internet I think it’s a security issue of old. There would be no file footprint on the hard drive. You could download it to the hard drive and then load it pretty easy. Then the software conventions come into play where coders are supposed to put their stuff in their own folder if it’s for their program and in system area if it’s for multiple programs. To be nice you are supposed to install the program so the users can easily find and remove/uninstall

---- Andre Krause wrote:> >

Can you explain why SDL.dll needs to exist in a different location than
the executable? You are asking how to accomplish something very
specific, but I have a feeling that understanding the overall goal might
be more useful to finding a solution that works for you.

–ryan.

i have a similar desire, so i just answer before jeremy:

its a specific problem, yes, but it is rather a problem of bad support by the
operating system. afaik windows seems to know only one way of dynamically
loading a library (LoadLibrary from a file) - and thats very limited. what about
loading dlls from a resource? what about loading dlls over the internet to a
memory buffer and starting the dll from that place? why is such basic stuff not
supported directly by some standard system library?

and its not hard to understand why one needs that. if you want to have an
install-free application, you just want to carry all your dll’s as a resource
with your executable. happily, my own little project is open source, so i have
no problem with static linkage, and do not to do nasty unportable dll stuff.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jeremy · October 31, 2007, 1:46pm

My situation is a bit unique yes. My project is an add-on mod to existing
games(Quake4,Doom3,Enemy Territory,HL2 engine games). Mods never add
dependend files to the games executable directory, and I sure as heck don’t
want to be copying stuff to their system directory. If I could load the dlls
from a subdirectory of the game of my choice, such as from the folders that
I have business reading from, I’d be set. I’m spawning an SDL window from
within a mod of these games for debugging, visualization, etc. The normal
paths of loading dependencies aren’t very useful. I don’t want to add bloat
to their game executable folder, or add stuff to their system folders, or
PATH, etc. As I feel any good application should work, I want to keep all
its dependencies under its own folder. The mod itself is a dynamic library,
not an executable, so the normal loading rules of executable folder aren’t
useful. Since I don’t have control over the dll loading to that extent I’m
left with the option of modifying SDL so I can instead do the LoadLibrary
and GetProcAddress bit myself, rather than the default linking arrangement.
Hope that clarifies my situation.

It’s not always feasible or desirable to be adding dlls to the executable
folder. Consider writing a plugin for 3dsmax, or maya or whatever. Your
plugin is a DLL, loaded from a plugins folder somewhere, you want to use
SDL/OpenGL to bring up a render window to visualize. You’re left with the
same issue. Either your plugin requires the dependent libraries in the root
app folder with the executable, and you’re fine with that. It’s the same
situation. In many situations, we wouldn’t even have the option of writing
additional files to existing app folders, due to lack of permissions to the
app folder, probably even the windows folder. Is your installer going to
require admin access just so you can spew some dlls to these crappy folders?
Or would you prefer to keep all your stuff under the same folder?
Applications cramming their junk everywhere is how windows got its DLL hell
nickname.

The difference is that my ‘plugin’ for these games are set up to all load
from a central location(it’s a bot for fps games). For example, Quake4,
Doom3, HL2 mods, etc all load my plugin ‘bot’ dlls from a central location,
such as an installed c:\program files\omni-bot All files are contained
within this install folder. This obviously isn’t the individual game
folders, and it would be wasteful to put multiple copies of dependencies in
all supported game folders.

Ultimately it’s an easy problem to solve if the project is from the ground
up your own executable and self contained. Using this sort of dll linking in
plugins or other dlls is where the suckage starts, as plugins and such are
often loaded from alternate places than the exe location, and leave you
needing to spread your dependencies to somewhere else to get them to load.
I’m more in favor of a LoadLibrary, GetProcAddress based loading procedure
than spewing dependent dlls all over the users machine.

JOn 10/31/07, necronology at cox.net wrote:

“if you want to have an
install-free application, you just want to carry all your dll’s as a
resource
with your executable.”

That’s how it is anyway. Just have the dll in the folder that the exe is
in.

As for loading a dll off of the internet I think it’s a security issue of
old. There would be no file footprint on the hard drive. You could download
it to the hard drive and then load it pretty easy. Then the software
conventions come into play where coders are supposed to put their stuff in
their own folder if it’s for their program and in system area if it’s for
multiple programs. To be nice you are supposed to install the program so the
users can easily find and remove/uninstall

---- Andre Krause wrote:

Can you explain why SDL.dll needs to exist in a different location
than

the executable? You are asking how to accomplish something very
specific, but I have a feeling that understanding the overall goal
might

be more useful to finding a solution that works for you.

–ryan.

i have a similar desire, so i just answer before jeremy:

its a specific problem, yes, but it is rather a problem of bad support
by the
operating system. afaik windows seems to know only one way of
dynamically
loading a library (LoadLibrary from a file) - and thats very limited.
what about
loading dlls from a resource? what about loading dlls over the internet
to a
memory buffer and starting the dll from that place? why is such basic
stuff not
supported directly by some standard system library?

and its not hard to understand why one needs that. if you want to have
an
install-free application, you just want to carry all your dll’s as a
resource
with your executable. happily, my own little project is open source, so
i have
no problem with static linkage, and do not to do nasty unportable dll
stuff.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Andre_Krause · October 31, 2007, 2:50pm

necronology at cox.net wrote:

“if you want to have an
install-free application, you just want to carry all your dll’s as a resource
with your executable.”

That’s how it is anyway. Just have the dll in the folder that the exe is in.

As for loading a dll off of the internet I think it’s a security issue of old. There would be no file footprint on the hard drive. You could download it to the hard drive and then load it pretty easy. Then the software conventions come into play where coders are supposed to put their stuff in their own folder if it’s for their program and in system area if it’s for multiple programs. To be nice you are supposed to install the program so the users can easily find and remove/uninstall

its a special case… for my little casual game, i dont want any installer
hassles (personally i hate installers, cluttering my system with dlls and
registry stuff and arbitrary start menu entries), and i dont want to put the
"burden" of unzipping onto casual gamers. i want a single exe download, thats
ready for execution as soon as the download is finished.

so i would have loved to have a way to append (compressed) dlls to my exe, load
them to memory and use them. there is a way to do that:

http://www.joachim-bauch.de/tutorials/load_dll_memory.html/en

but its so complicated i rather link statically. even if that means i can only
use generic software for openAL.

Matthias_Weigand · October 31, 2007, 8:18pm

Has someone already mentioned the possibility to wrap all resources
(executable, libraries, data files) in another executable? There are
tools around to generate some char[] arrays from files. This way you
could import all resources into another executable which writes these
resources to a temporary folder and executes the program.

Andre Krause wrote:> necronology at cox.net wrote:

“if you want to have an
install-free application, you just want to carry all your dll’s as a resource
with your executable.”

That’s how it is anyway. Just have the dll in the folder that the exe is in.

As for loading a dll off of the internet I think it’s a security issue of old. There would be no file footprint on the hard drive. You could download it to the hard drive and then load it pretty easy. Then the software conventions come into play where coders are supposed to put their stuff in their own folder if it’s for their program and in system area if it’s for multiple programs. To be nice you are supposed to install the program so the users can easily find and remove/uninstall

its a special case… for my little casual game, i dont want any installer
hassles (personally i hate installers, cluttering my system with dlls and
registry stuff and arbitrary start menu entries), and i dont want to put the
"burden" of unzipping onto casual gamers. i want a single exe download, thats
ready for execution as soon as the download is finished.

so i would have loved to have a way to append (compressed) dlls to my exe, load
them to memory and use them. there is a way to do that:

http://www.joachim-bauch.de/tutorials/load_dll_memory.html/en

but its so complicated i rather link statically. even if that means i can only
use generic software for openAL.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

icculus · November 1, 2007, 2:54am

its a specific problem, yes, but it is rather a problem of bad support by the
operating system. afaik windows seems to know only one way of dynamically
loading a library (LoadLibrary from a file) - and thats very limited. what about
loading dlls from a resource? what about loading dlls over the internet to a
memory buffer and starting the dll from that place? why is such basic stuff not
supported directly by some standard system library?

I suspect this isn’t the specific problem…I suspect LoadLibrary()
would work for him if he wanted to expend the tedious effort to load all
the symbols he needs, but mostly he wants the OS to find the DLL so it
can handle symbol resolution for him. That being said…

Having a need to load .dlls in a .zip file, I couldn’t find a way to
load a .dll from a memory buffer on any OS.

dlopen() wants a filename; you can sort of get around this by writing to
a temp dir (extra credit if it’s a ramdisk like /dev/shm), loading the
library, then unlinking the inode immediately, but it still requires a
write to the filesystem if not a physical disk, and if your system
crashes at the wrong moment, it may leave a file there…but once it
runs, it’s more or less working from a memory-only copy of the library.

A similar tapdance works on Windows; you can’t delete the file before
the library handle is closed, but you can open it with CreateFile()'s
FILE_FLAG_DELETE_ON_CLOSE flag to clean up. Probably also leaves a file
if there’s a bluescreen before your application ends. The dlopen()
window is much smaller at fractions of a second, but same problem.
Google around Dr. Dobbs Journal for the code to do this…you have to do
a few delicate things to make sure it works across all Windows variants.

Mac OS X and BeOS all fared similarly with their system-specific APIs.

If these systems could use a memory buffer, then I could feed it from an
.exe resource or a .zip file entry or whatever. None of them do.

I have seen userland code for Windows that parses a DLL in memory,
basically replicating LoadLibrary()…more or less, this is what Wine
does on Linux…but I bet that’ll break someday when the compiler or the
OS changes slightly, so I wouldn’t trust my app to include that code.

–ryan.

Jeremy · November 1, 2007, 11:50pm

Yea I tried for a while last night to do the converting of SDL to a true
dynamic library but it’s a nightmare so I gave up. I don’t need SDL that
badly to jump through those sort of hoops with a middle man dll. I’ve begun
converting my SDL usage to SFML, which I now prefer over SDL for my
situation, mainly due to static linkage and being in C++, and its simplicity
got me up and running very quickly.

Thanks for the input.

JeremyOn 11/1/07, Andre de Leiradella wrote:

I don’t want to add bloat to their game executable folder, or add
stuff to their system folders, or PATH, etc.

SetEnvironmentVariable only changes the current process’ environment.
But you’ll have to test if this environment is the one used by
LoadLibrary. I guess it is.

Since your application is already a DLL, you can just put it together
with all other DLLs in a separate folder. Now write another DLL, a small
one that will change the PATH variable and load your “main” DLL using
LoadLibrary. The other DLLs will be automatically loaded when the "main"
DLL is loaded.

This small DLL will have to have proxy functions that will just call
functions of your “main” DLL, whose pointers you’ll obtain using
GetProcAddress. I’m assuming that the number of functions of the bot API
is way less than the number of SDL functions you use in your code.

I already tried to LoadLibrary SDL.dll and a few others. I found myself
with loads of GetProcAddress and fighting with macro definitions, and
with the impression that my code would break with the very next SDL
release.

Cheers,

Andre

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Andre_de_Leiradella · November 2, 2007, 12:17am

I don’t want to add bloat to their game executable folder, or add
stuff to their system folders, or PATH, etc.

SetEnvironmentVariable only changes the current process’ environment.
But you’ll have to test if this environment is the one used by
LoadLibrary. I guess it is.

Since your application is already a DLL, you can just put it together
with all other DLLs in a separate folder. Now write another DLL, a small
one that will change the PATH variable and load your “main” DLL using
LoadLibrary. The other DLLs will be automatically loaded when the "main"
DLL is loaded.

This small DLL will have to have proxy functions that will just call
functions of your “main” DLL, whose pointers you’ll obtain using
GetProcAddress. I’m assuming that the number of functions of the bot API
is way less than the number of SDL functions you use in your code.

I already tried to LoadLibrary SDL.dll and a few others. I found myself
with loads of GetProcAddress and fighting with macro definitions, and
with the impression that my code would break with the very next SDL release.

Cheers,

Andre

Bill_Kendrick · November 2, 2007, 12:02am

OOC, why didn’t you statically link against SDL?
(You could adhere to the LGPL by providing objects against which SDL could
be re-statically-linked.)

So confused… but also barely paying attention

-bill!On Thu, Nov 01, 2007 at 04:50:22PM -0700, Jeremy wrote:

Yea I tried for a while last night to do the converting of SDL to a true
dynamic library but it’s a nightmare so I gave up. I don’t need SDL that
badly to jump through those sort of hoops with a middle man dll. I’ve begun
converting my SDL usage to SFML, which I now prefer over SDL for my
situation, mainly due to static linkage and being in C++, and its simplicity
got me up and running very quickly.

Jeremy · November 2, 2007, 12:11am

I mentioned that earlier. I’m not going to play the object file game either.
It’s easier to find a library that fits my needs better than maintain a
couple hundred meg zip of object files(and libraries?) from a large project
in the zero chance someone will want to re-link SDL. It’s wasted effort. SDL
is great, just not for my needs in this particular case. On the other hand
I’m growing to really like what SFML has to offer as part of this
experimentation with alternatives.

JOn 11/1/07, Bill Kendrick wrote:

On Thu, Nov 01, 2007 at 04:50:22PM -0700, Jeremy wrote:

Yea I tried for a while last night to do the converting of SDL to a true
dynamic library but it’s a nightmare so I gave up. I don’t need SDL that
badly to jump through those sort of hoops with a middle man dll. I’ve
begun
converting my SDL usage to SFML, which I now prefer over SDL for my
situation, mainly due to static linkage and being in C++, and its
simplicity
got me up and running very quickly.

OOC, why didn’t you statically link against SDL?
(You could adhere to the LGPL by providing objects against which SDL could
be re-statically-linked.)

So confused… but also barely paying attention

-bill!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Andre_Krause · November 2, 2007, 10:36am

Jeremy wrote:

I mentioned that earlier. I’m not going to play the object file game
either. It’s easier to find a library that fits my needs better than
maintain a couple hundred meg zip of object files(and libraries?) from a
large project in the zero chance someone will want to re-link SDL. It’s
wasted effort. SDL is great, just not for my needs in this particular
case. On the other hand I’m growing to really like what SFML has to
offer as part of this experimentation with alternatives.

its a shame that the license of SDL does not allow your scenario.

i am not into license stuff, but are there any good reasons, not to
change/enhance the license in the following way:

“you might use sdl in commercial projects and you are allowed to link
statically, but if you do so, you agree in providing product lifetime patches /
new executables on user request and in case of major version jumps of libSDL”.

something like this - that it is fixed in the license to support updates to the
project.

if i would do a commercial application where i want to have closed source, i
would do regular bug fixes and publish regular patches anyway - isnt that the
core meaning of “commercial support” anyway…

Leo_M_Cabrera · November 2, 2007, 12:53pm

Why is there a license anyway? It’s not like anyone would bootleg SDL or
make their own renamed version…

Andre Krause wrote:> Jeremy wrote:

I mentioned that earlier. I’m not going to play the object file game
either. It’s easier to find a library that fits my needs better than
maintain a couple hundred meg zip of object files(and libraries?) from a
large project in the zero chance someone will want to re-link SDL. It’s
wasted effort. SDL is great, just not for my needs in this particular
case. On the other hand I’m growing to really like what SFML has to
offer as part of this experimentation with alternatives.

its a shame that the license of SDL does not allow your scenario.

i am not into license stuff, but are there any good reasons, not to
change/enhance the license in the following way:

“you might use sdl in commercial projects and you are allowed to link
statically, but if you do so, you agree in providing product lifetime patches /
new executables on user request and in case of major version jumps of libSDL”.

something like this - that it is fixed in the license to support updates to the
project.

if i would do a commercial application where i want to have closed source, i
would do regular bug fixes and publish regular patches anyway - isnt that the
core meaning of “commercial support” anyway…

Bill_Kendrick · November 2, 2007, 2:49pm

Because the copyright owners own the copyright to SDL. Licensing it
under the LGPL ensures they get what they want back from the project,
while making it free for others to use (as in Free Software, capital F).

GPL and LGPL software is sometimes ‘bootlegged’, as you call it,
and people have been taken to court over this illegal use of copyrighted
software. For example, this week’s piece of news may be of interest:

"Settlement reached in Busybox-Monsoon GPL case"
http://www.linux.com/feature/120629

-bill!On Fri, Nov 02, 2007 at 08:53:49AM -0400, L-28C wrote:

Why is there a license anyway? It’s not like anyone would bootleg SDL or
make their own renamed version…