I’m building SDL 0.9.8 as a DLL using Codewarrior for Windows, and I’ve hit
a snag. When it’s being built (ie. when both _SDL_DYNAMIC_LIB and
BUILDING_SDL are true), SDL prepends every exported function name with ""
for some reason. Codewarrior then does the same thing, except to every
symbol. I think this is why I’m getting linker errors like “Undefined
symbol: _SDL_LockSurface”; there’s an extra underscore that the application
using the DLL doesn’t know about.
Can anyone help, or explain why SDL does this? I’m normally a Mac coder,
and I haven’t compiled DLLs before.
CDWJ
Cody DW Jones wrote:
I’m building SDL 0.9.8 as a DLL using Codewarrior for Windows, and I’ve hit
a snag. When it’s being built (ie. when both _SDL_DYNAMIC_LIB and
BUILDING_SDL are true), SDL prepends every exported function name with ""
for some reason. Codewarrior then does the same thing, except to every
symbol. I think this is why I’m getting linker errors like “Undefined
symbol: _SDL_LockSurface”; there’s an extra underscore that the application
using the DLL doesn’t know about.
Can anyone help, or explain why SDL does this? I’m normally a Mac coder,
and I haven’t compiled DLLs before.
CDWJ
I just built SDL on my Mac with CodeWarrior;
There’s at least one problem I had that when the header defined(XXX)
calls check for Metrowerks, they assume they’re running under BeOS (I
think). Certainly I had to fiddle with them (think it was SDL_mangle.h)
and add some extra checks.
I can try a Wintel build on a friend’s machine using CW 4 and see what
happens.
BTW, who’s working on the Mac version? I’m hoping to use SDL for a
project that needs to be very easily ported, but I’d like to develp on
the Mac. So I was thinkinging about jamming DrawSprocket underneath SDL
when a full screen video surface is requested. Any comments?
I’m still getting to grips with the library, however. The Mac build is
doign way strange things…
James Turner
I’m building SDL 0.9.8 as a DLL using Codewarrior for Windows, and I’ve hit
a snag. When it’s being built (ie. when both _SDL_DYNAMIC_LIB and
BUILDING_SDL are true), SDL prepends every exported function name with ""
for some reason. Codewarrior then does the same thing, except to every
symbol. I think this is why I’m getting linker errors like “Undefined
symbol: _SDL_LockSurface”; there’s an extra underscore that the application
using the DLL doesn’t know about.
Hmm… I don’t think Metroworks uses a different DLL import format for it
would
be incompatible to VC5… But maybe it does, then the problem should be in
begin_code.h, and you could look it up in the DirectX header files how it’s
done
there, or in the help…
Can anyone help, or explain why SDL does this? I’m normally a Mac coder,
and I haven’t compiled DLLs before.
I haven’t ever seen CodeWarrior in my life but I tried to compile the DLL
using VC++5
which worked (after some SDL_mageling) although I realized that it’s no use.
The downloadable
DLLs are compiled with more optimization (using gcc with mmx assembler
).
Just use the precompiled DLL and compile winmain.c and load.c (somewhere in
win32/ directories)
into your project or make a library of them and then link it. When compiling
this static
library, you mustn’t define BUILDING_SDL 'cause you aren’t building SDL but
the stub lib.
Note that you might want to try to define the WIN32 macro, which could make
it work…
I hope I didn’t say anything completely wrong here…
~ Paulus (@Paulus_Esterhazy)>
CDWJ
I’m building SDL 0.9.8 as a DLL using Codewarrior for Windows, and I’ve hit
a snag. When it’s being built (ie. when both _SDL_DYNAMIC_LIB and
BUILDING_SDL are true), SDL prepends every exported function name with ""
for some reason. Codewarrior then does the same thing, except to every
symbol. I think this is why I’m getting linker errors like “Undefined
symbol: _SDL_LockSurface”; there’s an extra underscore that the application
using the DLL doesn’t know about.
You need to build it and link it as a static library:
Define _BUILDING_SDL and _SDL_STATIC_LIB
If you figure out how to build dynamically loadable libraries under
Metrowerks, I would be obliged. Note that the key is in them being
dynamically loadable via LoadLibrary() or some such API.
Can anyone help, or explain why SDL does this? I’m normally a Mac coder,
and I haven’t compiled DLLs before.
Yes. Because SDL is dynamically loadable, the static library needs stub
functions which point to the real dynamically loaded versions. On some
operating systems there are name conflicts between the function pointer
and the dynamically loaded library. These are resolved by prepending an
underscore to the dynamic version of the function.
I’m still getting to grips with the library, however. The Mac build is
doign way strange things…
That’s because it’s still alpha. I’m doing the port (slowly) and everyone
who knows Mac well enough to help is busy.
If you could let me know what the Mac build is doing, I’d appreciate it.
I’m still getting to grips with the library, however. The Mac build is
doign way strange things…
That’s because it’s still alpha. I’m doing the port (slowly) and everyone
who knows Mac well enough to help is busy.
If you could let me know what the Mac build is doing, I’d appreciate it.
Can help, but I don’t use MacOS anymore - so ask me about problems and I
might be able to help…
njhOn Wed, 2 Dec 1998, Sam Lantinga wrote: