This may be a bit off-topic, it just belongs to a problem with
the http://libsdl.org/Xmingw32 hosted cross-compiler tarball.
I did want to crosscompile with that cross-compiler in a project
that made two dlls, where the second was dependent on the first
dll. You know, for win-dlls all references must be resolved at
link-time (-no-undefined for libtool), so I started to add lines
like -L$pathtootherdll -ldllname for each dll-build. Sadly, it
failed with a message, that the dll could not be found. But it
is there.
Looking thoroughly through the libtool-script (from latest
ltmain.sh 1.4) did reveal that the script will walk the -L-paths
looking with an ls -l ${path}/lib${dllname}* for possible
matches, and with the resulting list, it will check with objdump
and a file-magic (pe-386 in this case) if it really contains
objects belonging to the target platform. Even that it did have
the relevant non-installed lib in these checks, all checks failed
by a very simple reason - the referenced objdump was the one
from the $build-host, i.e. the linux-system, which simply did
not recognize the objectcode-types in the dll-archives.
Having traced the problem to this part, the actual problem
became apparent - the libsdl.org provided cross-compiler does
not have a cross-tools/i386-mingw32msvc/bin/objdump that
points to cross-tools/bin/i386-mingw32msvc-objdump as it
should, and therefore the PATH-changes by cross-make.sh are
just not enough to have it used the cross-tools objdump.
Creating the relevant backlink in the cross-tools filetree
did solve the problem. Of course, this is also a problem
in the libtool itself, as it should have to detect the
correct objdump utility in the case of a cross-compiling
libtool-environment. Enabling a check by a real autoconf
macro will probably resolve the name correctly throught the
config.cache, I’ll check that and submit this as a PR to the
libtool-group too, however the missing objdump in the
libsdl.org-tarball can hurt other people too, so I did put
this message in here, even that it is slightly off-topic.
have fun,
– guido http://savannah.gnu.org/projects/ac-archive
31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- h.r(*@)>+++ y++ 5++X-
oops, forget it… WIN32_DLL autoconf macros missing.
Looking thoroughly through the libtool-script (from latest
ltmain.sh 1.4) did reveal that the script will walk the -L-paths
looking with an ls -l ${path}/lib${dllname}* for possible
matches, and with the resulting list, it will check with objdump
and a file-magic (pe-386 in this case) if it really contains
objects belonging to the target platform. Even that it did have
the relevant non-installed lib in these checks, all checks failed
by a very simple reason - the referenced objdump was the one
from the $build-host, i.e. the linux-system, which simply did
not recognize the objectcode-types in the dll-archives.
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.
Having traced the problem to this part, the actual problem
became apparent - the libsdl.org provided cross-compiler does
not have a cross-tools/i386-mingw32msvc/bin/objdump that
points to cross-tools/bin/i386-mingw32msvc-objdump as it
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.
-RayOn Tuesday 19 June 2001 11:36, you 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 cross-tools/i386-mingw32msvc/bin/objdump that
points to cross-tools/bin/i386-mingw32msvc-objdump as it
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,
cheers,
– guido