Rockbox

Tasklist

FS#5858 - Allow cross-compiling W32 sdl sim

Attached to Project: Rockbox
Opened by Jonas Häggqvist (rasher) - Sunday, 20 August 2006, 00:02 GMT
Last edited by Rani Hod (RaeNye) - Friday, 22 September 2006, 00:08 GMT
Task Type Patches
Category Build environment
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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
make
This task depends upon

Closed by  Jonas Häggqvist (rasher)
Friday, 03 November 2006, 22:15 GMT
Reason for closing:  Accepted
Additional comments about closing:  I\'ll close this. The remaining problem can be opened as a bug if it turns out to be a problem for anyone.
Comment by Jonas Häggqvist (rasher) - Sunday, 20 August 2006, 21:58 GMT
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?"
cross=`input`
case "$cross" in
y|Y|yes|Yes)
if [ "0" == `sdl-config --libs |grep -c mwindows` ]; then
echo "Error: `which sdl-config` doesn't look like a windows sdl-config"
exit
fi
crosswincc
;;
esac

Turns into this:
if [ "0" != `sdl-config --libs |grep -c mwindows` ]; then
crosswincc
fi
Comment by Daniel Stenberg (bagder) - Sunday, 20 August 2006, 22:01 GMT
I'm all for doing the automatic check and ditch the question.
Comment by Jonas Häggqvist (rasher) - Sunday, 20 August 2006, 22:12 GMT
Okay, so it literally just adds this:
if [ "0" != `sdl-config --libs |grep -c mwindows` ]; then
__crosswincc
fi

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?
Comment by Jonas Häggqvist (rasher) - Sunday, 20 August 2006, 23:49 GMT
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?
Comment by Linus Nielsen Feltzing (linusnielsen) - Monday, 21 August 2006, 05:12 GMT
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.
Comment by Jonas Häggqvist (rasher) - Monday, 21 August 2006, 05:19 GMT
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. rockbox.zip 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?
Comment by Linus Nielsen Feltzing (linusnielsen) - Monday, 21 August 2006, 07:28 GMT
Well, I think you can safely strip everything from the cross-compiled sim build, since you always build your own if you are debugging.
Comment by Jonas Häggqvist (rasher) - Monday, 21 August 2006, 07:43 GMT
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?
Comment by Daniel Stenberg (bagder) - Monday, 21 August 2006, 07:46 GMT
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...
Comment by Jonas Häggqvist (rasher) - Monday, 21 August 2006, 07:51 GMT
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?
Comment by Daniel Stenberg (bagder) - Monday, 21 August 2006, 07:52 GMT
_very_ unlikely and we could just deem that not supported (for now)
Comment by Jonas Häggqvist (rasher) - Monday, 21 August 2006, 08:19 GMT
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)?
Comment by Jonas Häggqvist (rasher) - Monday, 21 August 2006, 10:04 GMT
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.
Comment by Jonas Häggqvist (rasher) - Monday, 28 August 2006, 12:20 GMT
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?
Comment by Rani Hod (RaeNye) - Friday, 22 September 2006, 00:05 GMT
The simulator is always built in debug mode, with -DDEBUG and -g, etc.
Maybe that's the problem?
Comment by Jonas Häggqvist (rasher) - Sunday, 24 September 2006, 11:37 GMT
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.
Comment by Rani Hod (RaeNye) - Sunday, 24 September 2006, 19:07 GMT
Why not just add postprocessing 'strip -s' to the Makefile (via tools/configure) ?

Loading...