[SDL] Dynamically loading SDL dlls

[Jeremy]

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.

J

On 10/30/07, Andre Krause <post at andre-krause.net> wrote:
>
> Michael Parker wrote:
> >
> >
> > On 10/30/07, *Jeremy* <jswigart at gmail.com <mailto:jswigart at gmail.com>>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20071030/1422f4a6/attachment.html