How can I cross compile SDL DLL?

SDL Development
1

I can cross compile SDL sources to create SDL.DLL ?

If I do

PATH=/usr/local/cross-tools/i386-mingw32/bin:$PATH
./configure --host=i386-linux --target=i386-mingw32
make; make install

I obtain only these files (located in /usr/local/cross-tools/i386-mingw32/lib)

libSDL-1.1.so.0.3.0
libSDL.a
libSDL.la
libSDL.so -> libSDL-1.1.so.0.3.0

Yes, of course I can find SDL.DLL in

SDL-devel-1.1.3-mingw32.tar.gz

but if I want cross-compile my own version of SDL.DLL, how can I do?

Thanks,
Enzo.–
E-mail enzo.gupi at tiscalinet.it
Home page http://enzogupi.interfree.it

2

Enzo wrote:

I can cross compile SDL sources to create SDL.DLL ?

If I do

PATH=/usr/local/cross-tools/i386-mingw32/bin:$PATH
./configure --host=i386-linux --target=i386-mingw32
make; make install

I obtain only these files (located in /usr/local/cross-tools/i386-mingw32/lib)

libSDL-1.1.so.0.3.0
libSDL.a
libSDL.la
libSDL.so → libSDL-1.1.so.0.3.0

Yes, of course I can find SDL.DLL in

SDL-devel-1.1.3-mingw32.tar.gz

but if I want cross-compile my own version of SDL.DLL, how can I do?

Thanks,
Enzo.

–
E-mail enzo.gupi at tiscalinet.it
Home page http://enzogupi.interfree.it

Did you try setting CC=i386-mingw32-gcc before you ran configure?
That might get it working. I say “might” because cross compiling
SDL is currently a big mess. The instructions are wrong, so if you
manage to build cross with it then count yourself lucky.

I have attached a patch to this email that would “fix” the current
SDL cvs if not for the fact that the cvs version of libtool that
I am using is completely busted so I will have to get it working
before I can actually test things out. You might be able to get
it working with an older version of libtool.

Mo DeJong
Red Hat Inc
-------------- next part --------------
Index: README.Win32===================================================================
RCS file: /cvs/SDL/README.Win32,v
retrieving revision 1.5.2.2
diff -u -r1.5.2.2 README.Win32
— README.Win32 2000/05/03 16:53:37 1.5.2.2
+++ README.Win32 2000/06/07 11:29:25
@@ -13,12 +13,12 @@
First, get an EGCS-based compiler for Win32, which can be found at:
http://www.devolution.com/~slouken/SDL/Xmingw32/index.html

  • Once you have the compiler, and copied the DirectX headers if you want them,
  • you are ready to build SDL for Win32. Make sure the cross-compiler is the
  • first gcc in your PATH, perhaps like this (using bash):
  • Once you have the compiler, and you have copied the DirectX headers if you
  • want to use DirectX, you are ready to build SDL for Win32. Make sure the
  • cross-compiler is on your PATH.
    PATH=/usr/local/cross-tools/i386-mingw32/bin:$PATH
  • and then (assuming you are running Linux on a PC):
  • ./configure --host=i386-linux --target=i386-mingw32; make; make install
  • If your cross compiler is named i386-mingw32msvc-gcc then use the folllowing:
  • ./configure --host=i386-mingw32msvc ; make; make install
    If you have already built SDL natively, you must do “make distclean”
    before you build for Win32.

@@ -30,14 +30,14 @@

This is easy once you have built the libraries:

  • cd test; ./configure --host=i386-linux --target=i386-mingw32; make
  • cd test; ./configure --host=i386-mingw32msvc ; make

==============================================================================
III. Building the Simple DirectMedia Layer demo programs:

Go to the directory containing the demo you want to build and type:

  • ./configure --host=i386-linux --target=i386-mingw32; make
  • ./configure --host=i386-mingw32msvc ; make

Common problems:
1. The compiler complains about including <windows.h>
Index: configure.in

RCS file: /cvs/SDL/configure.in,v
retrieving revision 1.25.2.68
diff -u -r1.25.2.68 configure.in
— configure.in 2000/06/06 17:17:50 1.25.2.68
+++ configure.in 2000/06/07 11:29:26
@@ -1,6 +1,9 @@
dnl Process this file with autoconf to produce a configure script.
AC_INIT(README)

+dnl Require version 2.14 of autoconf (needed for proper cross build support)
+AC_PREREQ(2.14)
+
dnl Set various version strings - taken gratefully from the GTk sources

Making releases:

@@ -37,12 +40,13 @@
AC_SUBST(LT_REVISION)
AC_SUBST(LT_AGE)

+dnl Detect the canonical host and build
+AC_CANONICAL_HOST
+AC_CANONICAL_BUILD
+
dnl Setup for automake
AM_INIT_AUTOMAKE(SDL, $SDL_VERSION)

-dnl Detect the canonical host and target build environment
-AC_CANONICAL_HOST
-AC_CANONICAL_TARGET

dnl Check for tools

@@ -52,7 +56,7 @@
AC_PROG_CC
AC_C_INLINE
AC_C_CONST
-case “$target” in
+case “$host” in
--beos*)
AC_PROG_CXX
;;
@@ -63,7 +67,7 @@
AC_PROG_INSTALL

dnl The alpha architecture needs special flags for binary portability
-case “$target” in
+case “$host” in
alpha*--linux)
if test x$ac_cv_prog_gcc = xyes; then
CFLAGS=“$CFLAGS -mcpu=ev4 -Wa,-mall”
@@ -208,7 +212,7 @@
CheckNASM()
{
dnl Make sure we are running on an x86 platform

  • case $target in
  • case “$host” in
    i?86*)
    ;;
    *)
    @@ -542,7 +546,7 @@
    [ --enable-pthread-sem use pthread semaphores [default=yes]],
    , enable_pthread_sem=yes)
    ac_save_libs=“$LIBS”
  • case “$target” in
  • case “$host” in
    --freebsd*)
    pthread_cflags=“-D_REENTRANT -D_THREAD_SAFE”
    pthread_lib=“-pthread”
    @@ -616,7 +620,7 @@

    See if we can use clone() on Linux directly

    use_clone=no
    if test x$enable_threads = xyes -a x$use_pthreads != xyes; then
  •    case "$target" in

  •    case "$host" in
       *-*-linux*)
           use_clone=yes
           ;;

@@ -718,7 +722,7 @@
SYSTEM_LIBS=“$SYSTEM_LIBS -lkstat”
}

-case “$target” in
+case “$host” in
--linux*)
ARCH=linux
CheckESD
@@ -1016,7 +1020,8 @@
;;
--cygwin* | --mingw32*)
ARCH=win32

  •    if test "$build" != "$target"; then # cross-compiling

  •    # FIXME : we should not hard code path names like this!

  •    if test "$cross_compiling" = "yes"; then
       ac_default_prefix=/usr/local/cross-tools/i386-mingw32
   fi
   CheckWIN32
3

Did you try setting CC=i386-mingw32-gcc before you ran configure?

No, I haven’t… I’ll try it

That might get it working. I say “might” because cross compiling
SDL is currently a big mess. The instructions are wrong, so if you
manage to build cross with it then count yourself lucky.

Uhm, I’m unhappy about it, cause cross-compiling is a very good
thing (I don’t need to reboot my machine to build executables for
Win32).

I have attached a patch to this email that would “fix” the current
SDL cvs if not for the fact that the cvs version of libtool that
I am using is completely busted so I will have to get it working
before I can actually test things out. You might be able to get
it working with an older version of libtool.

Thank you very much.
Enzo.

E-mail enzo.gupi at tiscalinet.it
Home page http://enzogupi.interfree.it

4

I can cross compile SDL sources to create SDL.DLL ?

You can, but you have to use dlltool manually to do it, since libtool
is completely broken and does some wierd versioning stuff with the DLL
name.

If you need me to build a special DLL for you with code already tested
using the .a library, let me know.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

5

Sam Lantinga wrote:

I can cross compile SDL sources to create SDL.DLL ?

You can, but you have to use dlltool manually to do it, since libtool
is completely broken and does some wierd versioning stuff with the DLL
name.

If you need me to build a special DLL for you with code already tested
using the .a library, let me know.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

This is exactly the problem I’ve been fighting with for the last
two days. The difference is that I’m trying to get all of the
latest libs compiled.

Apparently, libtool can be coerced to do the right thing, but not
using automake. So rather than hacking automake and libtool, which
are the nastiest things I’ve ever seen, I was thinking of making
a Makefile.mingw.in which configure can munge. Or possibly
a crossbuild.sh.in file. If I create such a thing for, say,
SDL, SDL_mixer, SDL_image, SDL_ttf (all the ones I’m interested
in), would you consider including them with the main distribution?
I’d do my best to make sure they will be easy to maintain.

-Ray

6

Apparently, libtool can be coerced to do the right thing, but not
using automake. So rather than hacking automake and libtool, which
are the nastiest things I’ve ever seen, I was thinking of making
a Makefile.mingw.in which configure can munge. Or possibly
a crossbuild.sh.in file. If I create such a thing for, say,
SDL, SDL_mixer, SDL_image, SDL_ttf (all the ones I’m interested
in), would you consider including them with the main distribution?
I’d do my best to make sure they will be easy to maintain.

Sure, that sounds great. :slight_smile:

Maybe even take the .a archive created by the cross automake stuff
and generate a .dll from it? You’d still need the export list I
suppose, and this can be found in any of the src/main/*/export
directories. … Just a thought.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

7

If you need me to build a special DLL for you with code already tested
using the .a library, let me know.

No, I needn’t it.
I asked it because I’m reading SDL’s configure scripts, and I’m
searching for the steps I have to do to create a DLL of my
libraries (that links to SDL.DLL).
I would be very happy if I could compile my libraries for linux
(already done with libtool) and cross-compile them in a DLL for win32.
Then I could make any new program simply linking to them
with a short Makefile.

Any suggestion?

Thank you very much.
Enzo–
E-mail enzo.gupi at tiscalinet.it
Home page http://enzogupi.interfree.it

8

Sam Lantinga wrote:

Apparently, libtool can be coerced to do the right thing, but not
using automake. So rather than hacking automake and libtool, which
are the nastiest things I’ve ever seen, I was thinking of making
a Makefile.mingw.in which configure can munge. Or possibly
a crossbuild.sh.in file. If I create such a thing for, say,
SDL, SDL_mixer, SDL_image, SDL_ttf (all the ones I’m interested
in), would you consider including them with the main distribution?
I’d do my best to make sure they will be easy to maintain.

Sure, that sounds great. :slight_smile:

Maybe even take the .a archive created by the cross automake stuff
and generate a .dll from it? You’d still need the export list I
suppose, and this can be found in any of the src/main/*/export
directories. … Just a thought.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

It is even easier than that. Newer versions of cross gcc for windows
support the -shared option. It will “do all the nasty stuff” needed
to create a .dll from a set of .o files. It is really cool.

If you want an example of how to create a configure.in and Makefile.in
script (no automake or libtool required) that can cross compile
for Windows you can grab the 8.4 version of Tcl. I know for a fact
that cross mingw of Tcl works because I just built one yesterday.
(go to http://dev.scriptics.com for the download).

Of course, the “best” think to do would be to keep hacking on
libtool to get it working, but m4 macros are not everyone’s
cup of tea.

Mo DeJong
Red Hat Inc

9

Enzo wrote:

I can cross compile SDL sources to create SDL.DLL ?

If I do

PATH=/usr/local/cross-tools/i386-mingw32/bin:$PATH
./configure --host=i386-linux --target=i386-mingw32
make; make install

I obtain only these files (located in /usr/local/cross-tools/i386-mingw32/lib)

libSDL-1.1.so.0.3.0
libSDL.a
libSDL.la
libSDL.so → libSDL-1.1.so.0.3.0

Yes, of course I can find SDL.DLL in

SDL-devel-1.1.3-mingw32.tar.gz

but if I want cross-compile my own version of SDL.DLL, how can I do?

Thanks,
Enzo.

–
E-mail enzo.gupi at tiscalinet.it
Home page http://enzogupi.interfree.it

Compile the object files as you are now, then use the dll creation tools here:
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/dllhelpers.html
to generate a dll using your cross compiled object files.

Here’s a quick and dirty script I’ve used, but I’m no expert.

dllwrap --export-all --output-def SDL.def --implib libSDL.a --driver-name gcc -o
SD
L.dll SDL.o SDL_RLEaccel.o SDL_active.o SDL_audio.o SDL_audiocvt.o SDL_audiomem.o
S
DL_blit.o SDL_blit_0.o SDL_blit_1.o SDL_blit_A.o SDL_blit_AK.o SDL_blit_K.o
SDL_bli
t_N.o SDL_bmp.o SDL_cdrom.o SDL_cursor.o SDL_dibaudio.o SDL_dibevents.o
SDL_dibvide
o.o SDL_dx5audio.o SDL_dx5events.o SDL_dx5video.o SDL_endian.o SDL_error.o
SDL_even
ts.o SDL_fatal.o SDL_joystick.o SDL_keyboard.o SDL_mixer.o SDL_mmjoystick.o
SDL_mou
se.o SDL_mutex.o SDL_pixels.o SDL_quit.o SDL_rwops.o SDL_surface.o SDL_syscdrom.o
S
DL_sysevents.o SDL_sysmouse.o SDL_systhread.o SDL_systimer.o SDL_syswm.o
SDL_thread
.o SDL_timer.o SDL_video.o SDL_wave.o SDL_wingl.o dummy.o -luser32 -lgdi32
-lwinmm
-ldxguid

10

Jeremy Peterson wrote:

Compile the object files as you are now, then use the dll creation tools here:
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/dllhelpers.html
to generate a dll using your cross compiled object files.

Here’s a quick and dirty script I’ve used, but I’m no expert.

…
…

Thanks much for the link and the examples.

Enzo.–
E-mail enzo.gupi at tiscalinet.it
Home page http://enzogupi.interfree.it

11

Sam Lantinga wrote:

Apparently, libtool can be coerced to do the right thing, but not
using automake. So rather than hacking automake and libtool, which
are the nastiest things I’ve ever seen, I was thinking of making
a Makefile.mingw.in which configure can munge. Or possibly
a crossbuild.sh.in file. If I create such a thing for, say,
SDL, SDL_mixer, SDL_image, SDL_ttf (all the ones I’m interested
in), would you consider including them with the main distribution?
I’d do my best to make sure they will be easy to maintain.

Sure, that sounds great. :slight_smile:

Maybe even take the .a archive created by the cross automake stuff
and generate a .dll from it? You’d still need the export list I
suppose, and this can be found in any of the src/main/*/export
directories. … Just a thought.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

I switched tactics on this one. I’ve patched libtool 1.3.4 to
“do the right thing” for windows DLLs. The only problem left
is with DLLs that export DATA symbols, which requires you do
hand-make a def file. My last attempt to allow an optional def
file resulted in breaking normal builds.

My patched libtool is in the SDL_gui project. When I get
everything working I’ll probably split out the patch and post
it someplace seperately.

So far, I have been able to successfully cross compile SDL,
SDL_image, and SDL_ttf, as well as my SDL_gui library.

The only difference I’ve noticed is that the resulting DLLs
use CRTDLL instead of MSVCRT. I don’t know if that will be
a problem.

-Ray

12

The only difference I’ve noticed is that the resulting DLLs
use CRTDLL instead of MSVCRT. I don’t know if that will be
a problem.

-Ray

I am guessing that you built a crtdll version of the cross
compiler instead of a msvcrt version. You really should
be using the msvcrt version.

I have attached a shell script that will download and
build a msvcrt version of the mingw cross compiler.

Mo DeJong
Red Hat Inc
-------------- next part --------------
A non-text attachment was scrubbed…
Name: build_cross_mingw32.sh
Type: application/x-sh
Size: 3632 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20000615/791e1024/attachment.sh

13

Mo wrote:

I am guessing that you built a crtdll version of the cross
compiler instead of a msvcrt version. You really should
be using the msvcrt version.

I have attached a shell script that will download and
build a msvcrt version of the mingw cross compiler.

Mo DeJong
Red Hat Inc

Actually, I used the one off of the sdl web site.
Perhaps we need to put a new version up there.

-Ray