Since I have been just asked off-list, let me clarify that
libtool-1.4 can indeed build dll easily. It has incorporated much
of the changes that Sam did to the libtool that you will find in
the SDL tarball, but some things are slightly different. The most
common error is to forget to specify “-no-undefined” on the libtool
linkline - the sdl-shipped libtool does it implictly, for libtool-1.4
you have to do it explicitly. Also get knowledge about the windows’
specifics like -mconsole or --export-all-symbols and such libtool’
options that get passed around to the dlltool.
My current problems are related to linking a dll that depends
on symbols of another dll, specifically another dll that is not
even installed, and even more specifically to another dll in
another (parallel) build-subdir. The sdl-shipped libtool would
not come even half the way that libtool-1.4 is doing easily.
Guido Draheim wrote:
Ray Kelm wrote:
You might want to try the patched version of libtool that is packaged into
SDL. A few other nuisance bugs have been covered with bandaids as well.
Yes, but Sam’s libtool misses a few functions that are ready in newest
libtool - and his changes should be nicely integrated into standard
libtool. On a general scale, they are indeed, with some things that are
just an “OOPS” for the user (e.g. the name-generation rule changed so that
libSDL-2-1-1.dll is used instead of SDL.dll). For other things that are
broken, I am about to nag the libtool-ml about
Anyway, I still like to come around with a patch for sdl12 to use
newest libtool … but perhaps we’ll wait. A patch for better macosx
support is still pending around libtool…
Having traced the problem to this part, the actual problem
became apparent - the libsdl.org provided cross-compiler does
not have a
should, and therefore the PATH-changes by cross-make.sh are
just not enough to have it used the cross-tools objdump.
This is something that I’ve changed recently in the cross.sh script, but not
emailed to Sam I’ll send that out ASAP.
applause … and I still dream of standard builds and tests of
gcc crosscompilers. Especially with the more embedded,handheld,settopbox
techspace, we see more and more an increase of crosscompiler usage.
And damn, I am not supposed to compile a project on a ps2, a beos-pad,
a palm or an (gasp) x-box itself, we’re going to use fine crosscompilers
then, or do we… not?
thanks for the answer, and have lots of fun,
– guido Edel sei der Mensch, hilfreich und gut
31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- h.r(*@)>+++ y++ 5++X-