# Cross-compiling issue

**URL:** <https://discourse.libsdl.org/t/cross-compiling-issue/4368>\
**Category:** SDL Development\
**Created:** [May 3, 2001, 1:06pm UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368 "2001-05-03T13:06:26Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andreas\_Schiffler](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/a/f1d935/32.png) [@Andreas\_Schiffler](https://discourse.libsdl.org/u/Andreas_Schiffler)\
**Post date:** [May 3, 2001, 1:06pm UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/1 "2001-05-03T13:06:26Z")

</div>

Hi all,

I’ve got another xmingw32 cross compiling problem … someone on the  
list might have an idea on how to solve it.

The win32 application I made by cross compiling with the xmingw32  
compiler available from the SDL site breaks (i.e. doesn’t start anymore

- “invalid executable”) after I “strip” the SDL.dll using the xmingw32  
strip tool.

Possible solutions to this problem would be:

– Get the SDL compile to work without the debugging info. The configure  
flag “–disable-debug” doesn’t seem to supress the “-g” during the  
compile. I inquired about this before, I’ll do it again … How does one  
get a fully optimized SDL build going using the autoconf system?

– Keep “strip” from screwing up the .DLL using some magic flags,  
updates, …

Thanks for any suggestions.

Bye  
Andreas

---

<div class="post-metadata">

**Author:** ![Ray\_Kelm](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/r/fbc32d/32.png) [@Ray\_Kelm](https://discourse.libsdl.org/u/Ray_Kelm)\
**Post date:** [May 4, 2001, 1:10am UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/2 "2001-05-04T01:10:21Z")

</div>

Andreas Schiffler wrote:

> Hi all,
> 
> I’ve got another xmingw32 cross compiling problem … someone on the  
> list might have an idea on how to solve it.
> 
> The win32 application I made by cross compiling with the xmingw32  
> compiler available from the SDL site breaks (i.e. doesn’t start anymore
> 
> - “invalid executable”) after I “strip” the SDL.dll using the xmingw32  
> strip tool.
> 
> Possible solutions to this problem would be:
> 
> – Get the SDL compile to work without the debugging info. The configure  
> flag “–disable-debug” doesn’t seem to supress the “-g” during the  
> compile. I inquired about this before, I’ll do it again … How does one  
> get a fully optimized SDL build going using the autoconf system?
> 
> – Keep “strip” from screwing up the .DLL using some magic flags,  
> updates, …
> 
> Thanks for any suggestions.
> 
> Bye  
> Andreas

Heh. This should be a FAQ by now… Yes, the version of strip  
in the version of binutils we use is broken for win32. I suspect  
that updating to a new version may solve the problem, although  
it could cause more 🙂

If I find time next week I can try a test build of the newer  
binutils to make sure SDL still works, and maybe we can get the  
updated tools onto [www.libsdl.org](http://www.libsdl.org), if Sam isn’t horribly busy.

-Ray

---

<div class="post-metadata">

**Author:** ![Guido\_Draheim](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/e19adc/32.png) [@Guido\_Draheim](https://discourse.libsdl.org/u/Guido_Draheim)\
**Post date:** [May 4, 2001, 1:56am UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/3 "2001-05-04T01:56:06Z")

</div>

Ray Kelm wrote:

> If I find time next week I can try a test build of the newer  
> binutils to make sure SDL still works, and maybe we can get the  
> updated tools onto [www.libsdl.org](http://www.libsdl.org), if Sam isn’t horribly busy.

Just in case it is not known - the newest libtool release 1.4  
_can_ crosscompile a dll - it has the patches from Sam, and even  
some extensions, e.g. sdl-patched libtool can not crosscompile  
a --module dll. I had to learn a few bits, but anyway newest  
libtool supports sharedlibs on quite a few more platforms than  
ever before. May be it’s a good time to update the toolchest  
even more - what do you think, Sam?

cheers,  
– guido [http://guidod.4t.com](http://guidod.4t.com)  
31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- y++ 5++X-

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [May 4, 2001, 4:05pm UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/4 "2001-05-04T16:05:29Z")

</div>

> > If I find time next week I can try a test build of the newer  
> > binutils to make sure SDL still works, and maybe we can get the  
> > updated tools onto [www.libsdl.org](http://www.libsdl.org), if Sam isn’t horribly busy.

> Just in case it is not known - the newest libtool release 1.4  
> _can_ crosscompile a dll - it has the patches from Sam, and even  
> some extensions, e.g. sdl-patched libtool can not crosscompile  
> a --module dll. I had to learn a few bits, but anyway newest  
> libtool supports sharedlibs on quite a few more platforms than  
> ever before. May be it’s a good time to update the toolchest  
> even more - what do you think, Sam?

Sounds good. I’ll have time next week to take patches and update  
the website. I’m getting married on Sunday! 🙂

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

---

<div class="post-metadata">

**Author:** ![Thomas\_Krennwallner](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/t/8e8cbc/32.png) [@Thomas\_Krennwallner](https://discourse.libsdl.org/u/Thomas_Krennwallner)\
**Post date:** [May 4, 2001, 4:51pm UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/5 "2001-05-04T16:51:10Z")

</div>

On Fri May 04, 2001 at 09:05:29AM -0700, the boisterous  
Sam Lantinga   
wrote to me:

> Sounds good. I’ll have time next week to take patches and update  
> the website. I’m getting married on Sunday! 🙂

Congrats to you, Sam! I have to say that you should spend as much time with  
your wife as possible and update the website a little later 😉

So long  
Thomas–

* * *

_/_**\ Obviously we do not want to leave zombies around.  
( ^ \> - W. Richard Stevens  
/ \   
(**/_)_

---

<div class="post-metadata">

**Author:** ![Karl\_Garrison](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@Karl\_Garrison](https://discourse.libsdl.org/u/Karl_Garrison)\
**Post date:** [May 4, 2001, 5:09pm UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/6 "2001-05-04T17:09:19Z")

</div>

Thomas Krennwallner wrote:

> Congrats to you, Sam! I have to say that you should spend as much time with  
> your wife as possible and update the website a little later 😉

What??? Why not take a laptop along on the honeymoon? 😉

> So long  
> Thomas

-Karl

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [May 10, 2001, 10:59pm UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/7 "2001-05-10T22:59:32Z")

</div>

> Just in case it is not known - the newest libtool release 1.4  
> _can_ crosscompile a dll - it has the patches from Sam, and even  
> some extensions, e.g. sdl-patched libtool can not crosscompile  
> a --module dll. I had to learn a few bits, but anyway newest  
> libtool supports sharedlibs on quite a few more platforms than  
> ever before. May be it’s a good time to update the toolchest  
> even more - what do you think, Sam?

Well, I just spent the afternoon copying the libtool release 1.4  
files into the SDL distribution and trying to build on various  
platforms. Maybe it’s my ignorance, but I wasn’t able to get the  
stock libtool to build a working library on Linux, much less a DLL  
for Windows.

Rather than spend a few days fixing libtool again, I’ll leave things  
the way they are, until somebody submits working patches.

The libtool must generate working libraries on Linux, FreeBSD, OpenBSD,  
BeOS, Mingw32 (native and cross-compiled), Cygwin, and MacOS X.  
The SDL libraries on Linux, FreeBSD, and OpenBSD should be dynamically  
linked against some system libraries and statically linked with others.  
The SDL library on Windows must be a DLL that depends on GDI32, USER32,  
and WINMM.  
The SDL library on BeOS must be a shared library that depends on root,  
be, media, game, device, and textencoding.  
The SDL library on MacOS X will be a static library.

If somebody is willing to get that much working with the latest libtool,  
I’ll be happy to accept updated patches.

See ya,  
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

---

<div class="post-metadata">

**Author:** ![Andreas\_Schiffler](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/a/f1d935/32.png) [@Andreas\_Schiffler](https://discourse.libsdl.org/u/Andreas_Schiffler)\
**Post date:** [May 10, 2001, 11:32pm UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/8 "2001-05-10T23:32:11Z")

</div>

Thanks to all who are looking into this cross-compiling thing.

Just to reiterate my original problem that got the ball rolling on the  
new libtool experiments (and to which I still havent’d found a  
solution):

How to I create a working, compact and small DLL using the xmingw32  
cross-compiler from Linux?

Currently I do it by manually editing the Makefile after a  
cross-configure run and removing the -g from the CFLAGS.

Is there a generic autoconf flag to turn off -g? Or some undocumented  
configure flag or quick hack? Or, if it is missing from the autoconf  
setup, maybe we should add it since ‘ld/strip’ is broken for xmingw32  
and SDL.dll always ends up beeing 1.5M in size. In my view the  
’–disable-debug’ option should actually not use -g. I am just not  
knowledgable enough with the autoconf system to make a patch that will  
do this …

Or would it be enough to simply update the tools that come with the  
xmingw32 archive on [libsdl.org](http://libsdl.org) - I’d volunteer to help recompile and  
assemble these tools if someone can give me hand or point me to the  
proper sources for these tools.

Bye now  
Andreas

---

<div class="post-metadata">

**Author:** ![Guido\_Draheim](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/e19adc/32.png) [@Guido\_Draheim](https://discourse.libsdl.org/u/Guido_Draheim)\
**Post date:** [May 12, 2001, 9:09am UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/9 "2001-05-12T09:09:26Z")

</div>

Andreas Schiffler wrote:

> Thanks to all who are looking into this cross-compiling thing.
> 
> Just to reiterate my original problem that got the ball rolling on the  
> new libtool experiments (and to which I still havent’d found a  
> solution):
> 
> How to I create a working, compact and small DLL using the xmingw32  
> cross-compiler from Linux?

What’s preventing it? did you add “-no-undefined” and given  
all libs that it depends on? And no “-lm” in LIBS!? (comes in  
implicitly by some mathcheck-autoconf macros)  
LIBS=`echo " $LIBS " | sed -e "s/ -lm / /"`

> Currently I do it by manually editing the Makefile after a  
> cross-configure run and removing the -g from the CFLAGS.

into configure.in, after ac\_lang\_c etc, and before output,  
CFLAGS=`echo " $CFLAGS " | sed -e "s/ -g / /"`  
just in case you know you really badly want to remove it _g_

> Is there a generic autoconf flag to turn off -g? Or some undocumented  
> configure flag or quick hack? Or, if it is missing from the autoconf  
> setup, maybe we should add it since ‘ld/strip’ is broken for xmingw32  
> and SDL.dll always ends up beeing 1.5M in size. In my view the  
> ‘–disable-debug’ option should actually not use -g. I am just not  
> knowledgable enough with the autoconf system to make a patch that will  
> do this …

The implicit addition of “-g” is really annyoing - just a me too,  
and some users of my packages noted that it doubles the file-size.  
Actually, these are extra segments in that file that don’t get  
loaded to memory, so one does not need to worry about the debug-info  
for your runtime system IIRC. Still - it’s an annoying “feature”.

> Or would it be enough to simply update the tools that come with the  
> xmingw32 archive on [libsdl.org](http://libsdl.org) - I’d volunteer to help recompile and  
> assemble these tools if someone can give me hand or point me to the  
> proper sources for these tools.

The autotools group is currently preparing a bigbang update,  
the newest libtool had to be used with a patched automake or  
better, just use it with the new automake but which in turn  
showed a few problems with new libtool IIRC, so there’ll be  
an automake update ('don’t know if it is already announced),  
and autoconf-NG will come out the very next days AFAICS.

I had been playing around with newest libtool lately, and  
especially crosscompiling with [GCC Win32 Build Environment](http://libsdl.org/Xmingw32) from  
linux to xmingw32 (but for my own projects) so I’ll see  
to help with these experiences in this quest as good as I can.

cheers,  
– guido [http://savannah.gnu.org/projects/ac-archive](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-

---

<div class="post-metadata">

**Author:** ![Guido\_Draheim](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/g/e19adc/32.png) [@Guido\_Draheim](https://discourse.libsdl.org/u/Guido_Draheim)\
**Post date:** [May 12, 2001, 9:09am UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/10 "2001-05-12T09:09:30Z")

</div>

Sam Lantinga wrote:

> > Just in case it is not known - the newest libtool release 1.4  
> > _can_ crosscompile a dll - it has the patches from Sam, and even  
> > some extensions, e.g. sdl-patched libtool can not crosscompile  
> > a --module dll. I had to learn a few bits, but anyway newest  
> > libtool supports sharedlibs on quite a few more platforms than  
> > ever before. May be it’s a good time to update the toolchest  
> > even more - what do you think, Sam?
> 
> Well, I just spent the afternoon copying the libtool release 1.4  
> files into the SDL distribution and trying to build on various  
> platforms. Maybe it’s my ignorance, but I wasn’t able to get the  
> stock libtool to build a working library on Linux, much less a DLL  
> for Windows.
> 
> Rather than spend a few days fixing libtool again, I’ll leave things  
> the way they are, until somebody submits working patches.
> 
> The libtool must generate working libraries on Linux, FreeBSD, OpenBSD,  
> BeOS, Mingw32 (native and cross-compiled), Cygwin, and MacOS X.  
> The SDL libraries on Linux, FreeBSD, and OpenBSD should be dynamically  
> linked against some system libraries and statically linked with others.  
> The SDL library on Windows must be a DLL that depends on GDI32, USER32,  
> and WINMM.  
> The SDL library on BeOS must be a shared library that depends on root,  
> be, media, game, device, and textencoding.  
> The SDL library on MacOS X will be a static library.
> 
> If somebody is willing to get that much working with the latest libtool,  
> I’ll be happy to accept updated patches.

I had been playing around with newest libtool lately, and  
especially crosscompiling with [GCC Win32 Build Environment](http://libsdl.org/Xmingw32) from  
linux to xmingw32 (but for my own projects) so I’ll see  
to help with these experiences in this quest as good as I can.

basically, I did install all new autotools in the local/cross-tools  
directory, cvs-autoconf, automake-1.4d, libtool-1.4 - just  
compile from source-tarballs using the correct --prefix (and  
host/target settings). The redo autotools for your project,  
it will not need ltconfig anymore, but depcomp as a new file.

It results in updating the project to all the brandnew autotools  
around - which is partly the most easiest but it will also bring  
about some problems ('had a problem on mac-os-x f.e.) just  
because these tools are so, well, neeewwww. As the autotools  
group is currently preparing a round of updates/releases, I’d  
propose to wait 2-3 weeks and see. I’ll keep you informed.

For anything about it, just keep on asking, at the moment I am  
a bit low on sparetime to make up a good patch-series for you  
to look into - updating to libtool-1.4 should be possible with  
a patched-old-automake even now without much problems. Mostly  
the problem is to delete (!!) ltconfig and update the libtool.m4  
along with patching automake to not install it - and it needs  
perhaps another option that I don’t remember at the moment.

cheers,  
– guido [http://savannah.gnu.org/projects/ac-archive](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-

---

<div class="post-metadata">

**Author:** ![slouken](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/s/ec9cab/32.png) [@slouken](https://discourse.libsdl.org/u/slouken)\
**Post date:** [May 22, 2001, 4:58am UTC](https://discourse.libsdl.org/t/cross-compiling-issue/4368/11 "2001-05-22T04:58:18Z")

</div>

> It results in updating the project to all the brandnew autotools  
> around - which is partly the most easiest but it will also bring  
> about some problems ('had a problem on mac-os-x f.e.) just  
> because these tools are so, well, neeewwww. As the autotools  
> group is currently preparing a round of updates/releases, I’d  
> propose to wait 2-3 weeks and see. I’ll keep you informed.

> For anything about it, just keep on asking, at the moment I am  
> a bit low on sparetime to make up a good patch-series for you  
> to look into - updating to libtool-1.4 should be possible with  
> a patched-old-automake even now without much problems. Mostly  
> the problem is to delete (!!) ltconfig and update the libtool.m4  
> along with patching automake to not install it - and it needs  
> perhaps another option that I don’t remember at the moment.

Great, thanks for the information. I hadn’t read this message  
before my last reply. 🙂

We’ll probably play with the new automake tools with the SDL 1.3  
development, and merge any improvements into the SDL 1.2 codebase.

See ya!  
-Sam Lantinga, Lead Programmer, Loki Software, Inc.