Carlo Bramini 2010-01-27 10:06:17 PST
When building third party software powered by libtool (like xine-lib and
several others) under Mingw+MSys, libSDL fails to link.
I got this message when building SDL video out component of xine-lib:
*** Warning: linker path does not have real file for library -lmingw32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libmingw32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/libmingw32.a
Apparently there is no need to manually add -lmingw32 for making libSDL
working.
If this flag is removed, everything is built without troubles.
If it has been added for fixing a cross-compiler, perhaps if would be a better
idea to adjust its SPECS file in the same manner it has been done in the true
one used by mingw on Windows (I'm just guessing why it exists here).
There is also another message received on the console:
*** Warning: linker path does not have real file for library -lSDLmain.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libSDLmain and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/libSDLmain.a
This message, like previous one, is caused by -no-undefined flag sent to
libtool when building shared libraries.
Actually adding an .la file with its dependencies solves the troubles, so I
believe it would be better to create it too in the build process of libSDL.
--HG--
branch : SDL-1.2
http://sourceforge.net/mailarchive/forum.php?thread_name 0703291652.38437.jwalt%40garni.ch&forum_name=cegcc-devel
Hi!
I just managed to compile SDL for Windows CE using the "mingw32ce"
configuration of http://cegcc.sourceforge.net. Test programs work as expected
(except for those using signals -- no POSIX on mingw32ce), and I didn't yet
encounter any problem.
While it was a pain to get everything compiled and running, the changes to
SDL are actually quite small (see attached SDL-ce.diff).
Unfortunately, the win32 headers shipped with cegcc are not 100% correct, and
it feels quite messy to work around them in SDL code, so those headers will
also need to be patched. (Attachment: win32api-ce.diff)
Since I had to apply the libtool patch from the cegcc patch, I have also ad ded
my copy of aclocal.m4 for SDL. I had to modify the cegcc libtool patch to
use "lt_cv_deplibs_check_method=pass_all" for mingw32ce, otherwise libtool
would not recognize the import libraries as valid for dynamic linking.
All these changes should not affect non-WinCE builds, so they could be
included in mainline SDL.
If you need some docs, you can use this description for a cross-compilation
README:
1) get cegcc from http://cegcc.sourceforge.net
2) build and install the "mingw32ce" variant (see cegcc installation docs)
3) patch w32api-headers (if not yet included in cegcc)
4) setup environment (customize the first three lines as you like):
PREFIX=/opt/mingw32ce
TARGET=arm-wince-mingw32ce
BUILD=`uname -m`-pc-linux-gnu
export PATH="$PREFIX/bin:$PREFIX/$TARGET/bin:$PREFIX/local/bin:$PATH"
export CFLAGS="${CFLAGS:- -O2 -g} -I$PREFIX/local/include"
export CPPFLAGS="${CPPFLAGS:- -O2 -g} -I$PREFIX/local/include"
export CXXFLAGS="${CXXFLAGS:- -O2 -g} -I$PREFIX/local/include"
export LDFLAGS="${LDFLAGS:- -O2 -g} -L$PREFIX/local/lib"
export HOST_CC="gcc"
export CC="$PREFIX/bin/$TARGET-gcc"
export CXX="$PREFIX/bin/$TARGET-g++"
export LD="$PREFIX/bin/$TARGET-ld"
export AS="$PREFIX/bin/$TARGET-as"
export AR="$PREFIX/bin/$TARGET-ar"
export RANLIB="$PREFIX/bin/$TARGET-ranlib"
export CONFIG_SHELL="/bin/sh"
5) build and install
./configure --target=$TARGET --host=$TARGET --build=$BUILD
make
make install
6) use (4) and (5) for any SDL-using software you want to cross-compile
7) copy $PREFIX/local/bin/SDL-1-2-0.dll into your executable directory on the WinCE machine
--HG--
branch : SDL-1.2
> BTW, when setting up parallel make, I usually use # cpus + 1, so a compile is
> running while disk access is going for another.
[From Ryan]
My experience is that this works well on Linux, but is actually slower on
PowerPC Mac OS X...not sure if that's an architecture issue or a scheduler
issue, though, and haven't tried it on Intel Mac OS X.
- A change to define CXX in fatbuild, which comforts the configure script a little, even if we don't use C++ anywhere.
- Some code to see how many CPU cores exist and parallelize make across them.
- CFLAGS that apply to both archs are specified seperately (-O3, -pipe, etc)
- -fvisibility=hidden for the gcc4 builds
- a "clean", "clean-ppc" and "clean-x86" command
- Fix to SDL_config_macosx.h for the HAVE_ALLOCA_H thing.
Now builds on an Intel Mac.
The attached patch changes configure.in to use "-framework FOO" instead of
"-Wl,-framework,FOO".
This avoid some issues with certain versions of libtool that do not handle
-framework properly.
Some versions of libtool will try to reorder the two parts of the option, or
render the 2nd part of the argument to the relative path of a non-existent
library.
Note: It is not enough if SDL uses a version of libtool that does this
correctly, because these -framework options show up in "sdl-config --libs".
Hence, some 3rd party apps which still ship with an old libtool have troubles
compiling under Mac OS X.
From: "alan buckley"
Subject: Re: Updating SDL for RISC OS
I've attached a zip file with three diffs to get SDL to build on RISC OS.
configure.in.diff and makedeps.sh.diff have been modified so that they
can build the assembler file in video/riscos. You may want to double
check these as I don't know a lot about unix shell programming.
(I've tested them cross-compiling on cygwin).
sdlsysthread.diff is the changes required to SDL_systhread.c for RISC
OS. As you suspected with these changes in place you can delete the
RISC OS specific threading code in thread/riscos.
I've also renamed SDL_riscosASM.s to SDL_riscosASM.S, but I'm never
quite sure how to rename files in CVS, so if you could to this it would
be appreciated.
