Trouble with SDL_LoadLibrary

I’m trying to load a .dylib with SDL_LoadLibrary in Mac, but
it always returns NULL. I tried passing “mylib.dylib”, “mylib”,
and “./mylib.dylib” as the parameter but none of these work. The
same code does work in Windows (loading a .DLL) and in Linux (loading
a .so).

Is there anything special to do when building the library? I replaced
-shared (as used in gcc Linux) for -dynamiclib to make the .dylib.

Thanks in advance,
–Gabriel

There doesn’t appear to be Mac OS X support for this function in SDL
(by looking at the source code SDL_loadso.c is the file in question).
However, it seems possible that with dlcompat installed it could work.
You will of course have to recompile SDL and ensure that USE_DLOPEN is
defined when compiling SDL_loadso.c. Max?

Yes that would be possible. And dlcompat even contains hacks to allow
loading shared libraries. And Apple now includes it with OS X 10.3.
However, Gabriel. please note: in general loading shared libraries is
totally unportable and you shouldn’t do it! Rather, create loadable
modules, which are meant for that particular acticity (on Linux, there
is no physical difference between the two; on OS X, there is).

Bye,

MaxAm 17.05.2004 um 03:57 schrieb Darrell Walisser:

Hello !

Yes that would be possible. And dlcompat even contains hacks to allow
loading shared libraries. And Apple now includes it with OS X 10.3.
However, Gabriel. please note: in general loading shared libraries is
totally unportable and you shouldn’t do it! Rather, create loadable
modules, which are meant for that particular acticity (on Linux, there
is no physical difference between the two; on OS X, there is).

I know what a Shared Lib. is, but what is a Loadable Module ?
Is there a way to create and load such a Module on every OS ?

CU

Hello !

Yes that would be possible. And dlcompat even contains hacks to allow
loading shared libraries. And Apple now includes it with OS X 10.3.
However, Gabriel. please note: in general loading shared libraries is
totally unportable and you shouldn’t do it! Rather, create loadable
modules, which are meant for that particular acticity (on Linux, there
is no physical difference between the two; on OS X, there is).

I know what a Shared Lib. is, but what is a Loadable Module ?
Is there a way to create and load such a Module on every OS ?

We wrote an explanation for this for the Fink project (as sadly, we
again and again encounter code which tries to dlopen shared libraries),
see http://fink.sourceforge.net/doc/porting/shared.php. Maybe also
<http://www.dwheeler.com/program-library/Program-Library-HOWTO/dl-
libraries.html> and
http://sources.redhat.com/autobook/autobook/autobook_159.html. In
fact I’d recommend to anybody interested in that subject to read
through chapter 17 (and maybe also 18) of the “Autobook”, available
online at
http://sources.redhat.com/autobook/autobook/autobook_toc.html – even
if you are not using automake/autoconf/libtool, this explains some of
the pitfalls and portability issues involved when dynamically loading
code (there are quite a few!).

Most (if not all) systems which support shared libraries should support
loadable modules, in fact, the SDL_LoadLibrary function’s name is a bit
misleading; it’s meant to load loadable modules, not libraries. But
since those two different things have a single identical implementation
on Linux, many coders don’t really know about the difference (leading
to less portable code). AFAIK, on Windows there is no difference
either, though I could be wrong.

Cheers,

MaxAm 17.05.2004 um 23:33 schrieb Torsten Giebl:

Neither Linux and Windows have any distinction between “modules” and
"libraries"; OSX is the odd man out, at least among those platforms.

That doesn’t mean that they’re different things with a single implementation;
it means they’re the same thing on those platforms. There’s simply no
distinction.

I’d suggest that SDL_LoadLibrary should abstract the difference on OSX.On Tue, May 18, 2004 at 12:54:29AM +0200, Max Horn wrote:

Most (if not all) systems which support shared libraries should support
loadable modules, in fact, the SDL_LoadLibrary function’s name is a bit
misleading; it’s meant to load loadable modules, not libraries. But
since those two different things have a single identical implementation
on Linux, many coders don’t really know about the difference (leading
to less portable code). AFAIK, on Windows there is no difference
either, though I could be wrong.


Glenn Maynard

Most (if not all) systems which support shared libraries should
support
loadable modules, in fact, the SDL_LoadLibrary function’s name is a
bit
misleading; it’s meant to load loadable modules, not libraries. But
since those two different things have a single identical
implementation
on Linux, many coders don’t really know about the difference (leading
to less portable code). AFAIK, on Windows there is no difference
either, though I could be wrong.

Neither Linux and Windows have any distinction between “modules” and
"libraries"; OSX is the odd man out, at least among those platforms.

That doesn’t mean that they’re different things with a single
implementation;
it means they’re the same thing on those platforms. There’s simply no
distinction.

I am aware that they are the very same thing on Linux and Windows.
However, the problem is, they are still different concepts. Writing
code which tries to load a shared library has porting troubles, and not
just to OSX. The proper solution is to use loadable modules; luckily
that means few (if any) changes to our existing Windows/Linux build
chains.

I’d suggest that SDL_LoadLibrary should abstract the difference on OSX.

That’s a bad idea, IMO. While we demonstrated with dlcompat that it’s
possible to emulate dlopening of a shared library, that hack has a lot
of drawbacks. I don’t agree with adding a workaround to SDL for
something which inherently is incorrect use by the client developer. If
you simply change your build chain to generate a loadable module
instead of a shared library, at least on OSX (and other unices and OSes
which share this problem), you’ll have no trouble either.

Bye,

MaxAm 18.05.2004 um 02:58 schrieb Glenn Maynard:

On Tue, May 18, 2004 at 12:54:29AM +0200, Max Horn wrote: