Talk:Compiling for Android: Difference between revisions
(→Speculation: correction: libfb linked to X11 libs by default) |
|||
| Line 109: | Line 109: | ||
Look at compile-using-toolchain.sh for how to invoke scons (you'd build Game/Custom directly using scons). You'd probably also need to add the directory containing a build of libSDL.so (and libSDL_mixer.so (or use music=silence)) cross-compiled to the Raspberry Pi to the CXXLINKFLAGS variable in SConscript (we ought to set the standard LDFLAGS variable instead). | Look at compile-using-toolchain.sh for how to invoke scons (you'd build Game/Custom directly using scons). You'd probably also need to add the directory containing a build of libSDL.so (and libSDL_mixer.so (or use music=silence)) cross-compiled to the Raspberry Pi to the CXXLINKFLAGS variable in SConscript (we ought to set the standard LDFLAGS variable instead). | ||
[[User:Sorlok reaves|S'orlok Reaves]] ([[User talk:Sorlok reaves|talk]]): I've got one coming in the mail ---and I noticed you separated the Android/ARM targets in a recent commit, thanks! I'll give it a whirl once my device arrives. | |||
Revision as of 01:58, 11 June 2013
Bob the Hamster (talk) 22:01, 1 June 2013 (PDT): I am a bit confused by the freebasic instructions. I understand that I need to create a config.mk and put some stuff in it. I don't know what the toolchain is, except that the android/compile-using-toolchain.sh script seems to populate it, but I have not yet gotten to the step where I try that. Why /tmp ? That seems like a really strange place to put anything.
Bob the Hamster (talk) 22:09, 1 June 2013 (PDT): My config.mk looks like this:
ENABLE_PREFIX=1 prefix=/home/james/misc/fbc-0.90-android PATH:=/tmp/android-toolchain/bin:$(PATH) TARGET_PREFIX=arm-linux-androideabi-
but when I do make compiler it says:
james@rhinoctopus:~/src/misc/fbc-tmc$ make compiler makefile:414: target `src/rtlib/arm-linux-androideabi-' given more than once in the same rule. makefile:414: target `obj' given more than once in the same rule. makefile:414: target `freebasic' given more than once in the same rule. makefile:445: warning: overriding commands for target `lib/arm-linux-androideabi-' makefile:417: warning: ignoring old commands for target `lib/arm-linux-androideabi-' makefile:448: warning: overriding commands for target `lib/arm-linux-androideabi-' makefile:445: warning: ignoring old commands for target `lib/arm-linux-androideabi-' makefile:451: warning: overriding commands for target `lib/arm-linux-androideabi-' makefile:448: warning: ignoring old commands for target `lib/arm-linux-androideabi-' makefile:459: warning: overriding commands for target `lib/arm-linux-androideabi-' makefile:451: warning: ignoring old commands for target `lib/arm-linux-androideabi-' makefile:462: *** multiple target patterns. Stop.
I assume this is just because I don't know jack about makefiles :)
TMC (talk): That was quite puzzling, but I've discovered that it must be because you have a space at the end of the TARGET_PREFIX line. I sure hate makefiles.
The standalone NDK toolchain is the bare essentials copied from the NDK: tools, headers and libraries to target a single specific arch+android version using a specific GCC/Clang version. I simply put it in /tmp because that's what the NDK docs suggested. Probably because you install multiple of them for your different targets then can delete when done. My own config.mk:
PATH:=/tmp/android-toolchain/bin:$(PATH) TARGET_PREFIX=arm-linux-androideabi- ENABLE_PREFIX=1 CFLAGS := -Wfatal-errors -O0 -g prefix=/home/ralph/local/fbc-0.90-android V=1
Looking closer at the makefile, I see $prefix is the install location, so you definitely want to specify that, since it's not a normal build of FB; though you could build non-crosscompiling versions of rtlib and fbgfx libraries and install those too and it should work
Bob the Hamster (talk) 12:26, 2 June 2013 (PDT): Yup! You are right. That one extra space was throwing it off.
debuginfo crash
Bob the Hamster (talk) 13:04, 2 June 2013 (PDT): I was able to get through the whole compiling process, and ended up with an apk, but when I ran it on the device, it crashed with a file-not-found in debuginfo http://pastebin.com/raw.php?i=gxyATZTg
TMC (talk): What is line 352 in common.rbas.bas for you? For me, with no modifications to common.rbas, it is "sizeerror = -1". I don't see which line in debuginfo could throw that error, unless it's possible for a "file not found" error to be printed when attempting to access a file which has already been successfully opened...
You could try using ndk-gdb (instructions on Android Port to see where exactly in libfb the error is thrown from. Also it's a mystery how debuginfo is being called before startup, so the backtrace will be very interesting.
Bob the Hamster (talk) 07:29, 3 June 2013 (PDT): Line 352 in common.rbas.bas is the same for me as for you. Nothing looks unusual in that file. I tried ndk-debug but the SDL logo flickers on the device's screen and the crashes before gdb has a chance to connect to it: http://pastebin.com/raw.php?i=BcEzMxKu
TMC (talk): Having another look at the generated C and looking through the rtlib source, that error message still looks impossible. There is no place where line number 352 is passed to anything, unless its line 352 in a different file. Maybe you changed something and forgot to recompile using scons before invoking build.sh? Also once scons stopped because of an error which I failed to notice but build.sh still built successfully, which was quite confusing.
I suggest adding "sleep(3000)" at the top of debuginfo to allow gdb time to attach. The ndk-gdb script contains a wait of several seconds.
Bob the Hamster (talk) 07:17, 4 June 2013 (PDT): Oh! Duh! I did have a change that I had not realized. I had forgotten that I was messing around with CompatibilityHacksAdditionalPreloadedSharedLibraries in my AndroidAppSettings.cfg
Although now I am confused by other problems. I saw the same "undefined reference to 'SDL_main" error, but when I messed with my symlinks I seem to have screwed up everything, and compile-using-toolchain.sh doesn't seem to create any files in android/tmp I am going to start over.
Bob the Hamster (talk) 07:53, 4 June 2013 (PDT): Yay! I followed the instructions more carefully, and now I can build a working apk! I had failed to notice the difference between scons android=1 and scons android-source=1
TMC (talk): Great :). Were you trying to preload libapplication.so? I could see that leading to problems, though I still don't understand how the error message could have been caused.
The files in android/tmp are created by android_source_files in ohrbuild.py, which really ought to be replaced with a better system. Either calling the standalone toolchain from scons, or continuing with a two phase build with our own Android.mk to replace the unsuitable one in the SDL port.
Just like on all other platforms, unless you compile with debug=0 (which we do for Windows nightly builds but not Mac or Linux), when FB encounters an error it will immediately kill the program (I really ought to install a hook in the rtlib to handle this better!). That includes when OPEN fails, which is pretty likely on Android because of all the paths that need updating.
Ubuntu
S'orlok Reaves (talk): Just thought I might add that, for Ubuntu users, Free Basic won't compile unless you install lib32ncurses5-dev. I'm not sure why Free Basic complained about this particular library; for everything else, "libWhatever-dev" seemed to work.
TMC (talk): Right, that's at the "make compiler" step. The fbc compiler itself is a 32 bit binary (although there is a 64 bit branch of FB, which didn't yet work last time I checked). The rtlib of course shouldn't depend on anything outside the standalone toolchain.
Symlinks
S'orlok Reaves (talk): I'm getting "undefined reference to 'SDL_main'" when I try to run ./build.sh inside the sdl-android directory. Is anyone else getting this?
S'orlok Reaves (talk): Ok, I figured it out. The wiki text "Create a symlink from sdl-android/project/jni/application/src to sdl-android/project/jni/application/ohrrpgce" was somewhat inaccurate. You actually want to do something like this:
cd sdl-android
ln -s ohrrpgce project/jni/application/src
...because build.sh expects the link to point locally to "ohrrpgce". If you point it to anything else (subfolder, absolute path, etc.) it will fail.
TMC (talk): Yeah, I found the arguments to ln to be quite unintuitive. ln and ln -s work quite differently: ln (for hardlinks) takes a normal file path, while ln -s takes a string which is put into the symlink and is relative to the symlink's location, not the current directory. Some versions of GNU ln takes an -r argument (relative) to make the ln -s destination relative to the current directory instead.
S'orlok Reaves (talk): I would recommend that new developers generally avoid hard symlinks; otherwise, a stray "rm" command can take out the OHR and Free Basic directories as well. At least for the last step (linking the current SDL project to "src") you should definitely use a soft link unless you're 100% sure you want a hard link. (Note that I used only soft links for compiling).
Speculation
S'orlok Reaves (talk): This is just wild speculation, but it occurs to me that the Raspberry Pi uses an ARM chip and is known to run SDL apps. Do you think the same basic steps here would work for that? (Obviously I would have to create my own toolchain instead of using the NDK's version.) In particular, I'm wondering if, given a properly configured toolchain, FB should be able to "make compiler" and "make rtlib". Any thoughts?
TMC (talk): That definitely should be possible! However I see lots of little changes are needed. Have you got a Raspberry Pi? I'd love to see it happen.
AFAIK android uses identical ABIs to other ELF unix OSes on the same CPU architectures (though I get the hint that there may be slight differences in the linker due to some platforms not following the standards to the letter).
My changes to both FB and the OHR conflate Android and ARM in several places. You would want to compile both for a GNU/Linux target instead of Android (if you run a normal GNU/Linux distrib with ncurses and X11 on the RPi). SConscript needs several changes in addition to the ones I just made. If SDL on the RPi uses the frame buffer, then you may not want to link with the X11 libs (actually libfb still links to X11 by default, unless you add -DDISABLE_X11 to config.mk). And it'll need to know where to find the FB libs (it looks like the Raspberry Pi toolchain uses a platform triple of arm-bcm2708hardfp-linux-gnueabi, so you'll probably edit SConscript where I hardcoded arm-linux-androideabi). Looking through my changes to FB, it looks like the only thing which needs changing for GNU/Linux on ARM is to edit rtlib/static/fbrt0.c to use __attribute__((constructor)). fbc should actually be fine for cross compiling to any 32 bit target as long as it's invoked with "-arch arm" (well not quite true: it assumes that it knows how all structures are laid out in memory (that they are the same as laid out by GCC on x86... I'm surprised this hasn't blown up on ARM!)
Look at compile-using-toolchain.sh for how to invoke scons (you'd build Game/Custom directly using scons). You'd probably also need to add the directory containing a build of libSDL.so (and libSDL_mixer.so (or use music=silence)) cross-compiled to the Raspberry Pi to the CXXLINKFLAGS variable in SConscript (we ought to set the standard LDFLAGS variable instead).
S'orlok Reaves (talk): I've got one coming in the mail ---and I noticed you separated the Android/ARM targets in a recent commit, thanks! I'll give it a whirl once my device arrives.