Cross-compiling issue

SDL Development
1

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

2

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 :slight_smile:

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, if Sam isn’t horribly busy.

-Ray

3

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, 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
31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- y++ 5++X-

4

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, 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! :slight_smile:

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

5

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! :slight_smile:

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 :wink:

So long
Thomas–

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

6

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 :wink:

What??? Why not take a laptop along on the honeymoon? :wink:

So long
Thomas

-Karl

7

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.

8

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 - 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

9

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 - 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 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
31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- h.r(*@)>+++ y++ 5++X-

10

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 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
31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- h.r(*@)>+++ y++ 5++X-

11

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. :slight_smile:

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.