• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Infrastructure → Build environment
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by rasher - 2006-08-20
Last edited by RaeNye - 2006-09-22

FS#5858 - Allow cross-compiling W32 sdl sim

This patch will allow you to crosscompile the SDL simulator for Windows from Linux.

You will need a cross-compiled version of SDL as well. With this patch applied, the following steps are necessary to produce your first crosscompiled build:

First you need to build SDL:
./configure –host=i586-mingw32msvc –prefix=$PREFIX
make && make install

You really should set a prefix, since the sdl-config will overwrite your native sdl-config otherwise.

After that, you just need to run rockbox configure with PATH set so the crosscompiled sdl-config is first
PATH=$PREFIX/bin:${PATH} ../tools/configure

Closed by  rasher
2006-11-03 22:15
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

I\'ll close this. The remaining problem can be opened as a bug if it turns out to be a problem for anyone.

I have a couple of questions, that I guess I should have written yesterday:

1) Is this the proper place in the script to place this check (inside simcc)?

2) Should I ditch the question entirely, so I simply check if sdl-config is from a windows SDL, and then crosscompile if it is (assuming that, if that’s the case, the person must know what he’s doing (seeing as he’s already crosscompiled SDL and set PATH accordingly)?

So this:

     echo "Crosscompile for windows?"
     case "$cross" in
         if [ "0" == `sdl-config --libs |grep -c mwindows` ]; then
             echo "Error: `which sdl-config` doesn't look like a windows sdl-config"

Turns into this:
if [ “0” != `sdl-config –libs |grep -c mwindows` ]; then



Project Manager

I’m all for doing the automatic check and ditch the question.

Okay, so it literally just adds this:
if [ “0” != `sdl-config –libs |grep -c mwindows` ]; then

In the sdl sim part, which is enough. Is that fine to commit? (can’t see how it’d hurt anything, if people has a cross-compiled sdl lying around, there’s probably a reason).

One thing though - the binaries are huge. The codecs will not fit the codec buffer and so on. They really need to be stripped before being usable. What to do?

Is there any way to avoid building the w32 sim with all kinds of debugging symbols? I can’t imagine they’d be of much use - would gdb even run on windows natively?

For now, I have created a “strip” target in the makefile, which works fine, but it seems like I should not have to do that.

Slightly related, is there any reason to display the sim-version choser anymore? The x11 and win32 sim are completely gone now, not just hidden. Simply hardcoding it to sdl, and skipping the question seems the simplest way to go about it, allowing to add back another version with minimal inconvenience.

Or should I completely rip out all parts that deal with the differing sim-version, and put that in another task?

Project Manager

Debugging the Win32 simulator with gdb is perfectly possible, and is one of the main reasons to build a sim version in the first place.

What to do then? Is there some “level” of debugging symbols that can be disabled or something like that, because as things are right now, the win32 sdl sim is not really usable (at least when compiled in Linux).

The AAC codec is >1mb, so that and a few others will not run at all. I’m sure many of the plugins are huge as well. ends up being >10mb.

Do you know if this is the case when the sim is built with cygwin as well?

Also, is the sim “standalone” when compiled with cygwin, or will it require cygwin dlls?

Project Manager

Well, I think you can safely strip everything from the cross-compiled sim build, since you always build your own if you are debugging.

It would be nice to figure out what causes the following, rather dramatic, difference though:

$ ls -l h120-sim{,-w32}/apps/codecs/aac.codec
-rw-r–r– 1 rasher rasher 1074515 Aug 21 09:36 h120-sim-w32/apps/codecs/aac.codec
-rw-r–r– 1 rasher rasher 675669 Aug 21 09:38 h120-sim/apps/codecs/aac.codec

Are windows binaries simply huge, is this a problem with mingw, or do I need to set/unset some flags or something?

Can I avoid the binaries getting this big, or will I need to add the method of running strip after compiling?

Project Manager

Without having a solution to the actual size problem, do note that we can use ld -s (or –strip-all) when linking to strip at once. So you could set that option in the configure already, removing the need for a special strip target…

That sounds like a reasonable (and easy) way around it, of course, still with the disadvantage that you can now no longer use gdb on the result.

How likely is it though, that someone builds the sim on Linux, to run it on windows to use gdb with it?

Project Manager

_very_ unlikely and we could just deem that not supported (for now)

I cannot make this work. It should be as simple as adding -s to LDOPTS shouldn’t it? I have the following line in the Makefile:

export LDOPTS=-s -L/home/rasher/rockbox/build-env/w32/lib -lmingw32 -lSDLmain -lSDL -mwindows

Would there be any objections to committing the simple version, that produces large binaries (but otherwise works fine)?

I still cannot make this work. It’s as if the -s LDOPTS is not having any effect. Is it not the correct play to add the -s? Doesn’t really seem like it. I guess I’m just lost in the Rockbox build-system.

Would it be okay to commit the version that simply enables crosscompiling, hoping someone else could fix this? It’s not like it breaks anything, it just doesn’t work as good as it could.

I have committed the change mentioned on Monday, 21 August 2006, 12:12AM, but the problem with the binary-size remains. I’m beginning to think it’s a mingw32 or SDL thing, and not Rockbox. The reason for this is, that the SDL.dll in my SDL installation is 2mb, which shrinks to about 200kb when stripped. Is it possible that bits of SDL is “filling up” the Rockbox binaries?

The simulator is always built in debug mode, with -DDEBUG and -g, etc.
Maybe that’s the problem?

That’s most definitely it. However, I still don’t understand quite why the binaries get that huge (same is true for my cross-compiled SDL library). I’m suspecting mingw32 somehow, but can’t really back it up.

If someone with a bit more knowledge of the whole build-system and/or building stuff in general could try out crosscompiling, it’d be much appreciated.

Why not just add postprocessing ‘strip -s’ to the Makefile (via tools/configure) ?


Available keyboard shortcuts


Task Details

Task Editing