Talk:Compiling for Android
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.
Contents
debuginfo crash[edit]
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[edit]
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[edit]
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[edit]
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.
TMC (talk): Cool. I might get around to some other clean up before then. Those SConscript changes were just one thing needed.
Hacking my way through the RPi[edit]
S'orlok Reaves (talk): So I've started working on cross-compiling for Raspberry PI. I'm stuck on the "make rtlib" step of FreeBasic (I'll work through it more later, but I figured I've reached a stopping point for tonight so might as well document it.)
First, I installed crosstools-ng, which is by far the most common suggestion for setting up a toolchain. I followed this post for the most part: http://www.kitware.com/blog/home/post/426
Then, I ssh-ed into the RPi and installed libSDL1.2-dev, and all related libraries. Then I did this:
cd ~/opt/rpi_sync rsync -rl pi@192.168.1.110:/usr .
Following that, I checked out the FreeBasic repo listed above and used this config.mk file:
ENABLE_PREFIX=1 prefix=/home/sethhetu/opt/fbc-0.90-rpi PATH:=/home/sethhetu/opt/x-tools/arm-unknown-linux-gnueabi/bin:$(PATH) CFLAGS := -I/home/sethhetu/opt/rpi_sync/usr/include -I/home/sethhetu/opt/rpi_sync/usr/include/arm-linux-gnueabihf TARGET_PREFIX=arm-unknown-linux-gnueabi- V=1
Note that CFLAGS; I was guessing that this would allow me to use the same headers on both the RPi and my laptop. This is just a guess!
At that point, I ran:
make compiler
It ran to completion, then:
make rtlib TARGET=arm-unknown-linux-gnueabi
It fails with:
arm-unknown-linux-gnueabi-gcc -Wall -Werror-implicit-function-declaration -I/home/sethhetu/opt/rpi_sync/usr/include -I/home/sethhetu/opt/rpi_sync/usr/include/arm-linux-gnueabihf -c src/rtlib/linux/sys_portio.c -o src/rtlib/arm-unknown-linux-gnueabi-obj/sys_portio.o src/rtlib/linux/sys_portio.c: In function 'fb_hIn': src/rtlib/linux/sys_portio.c:11:2: error: impossible constraint in 'asm'
The line in question:
__asm__ volatile ("inb %1, %0" : "=a" (value) : "d" (port));
Here's where I'm stumped. If it was a header-file error, I wouldn't be surprised. But it's a c file, and involves the correct toolchain item (arm-unknown-linux-gnueabi-gcc). And the same FreeBasic repo compiled fine for Android with a similar config.mk (but no CFLAGS in this case).
Anyway, I'll debug more this weekend. Any suggestions would be appreciated.
I hadn't noticed that there was asm in use there. To do things properly, we'll want to move that stuff into an x86-specific file, and also provide an ARM implementation of port IO. I assume that anyone using a RPi for hardware hacking and using FB will want ARM implementations of that. I don't know anything about that stuff. But it apears that ARM doesn't have separate IO instructions. Someone said:
The ARM architecture doesn't specify a separate I/O space -- everything is memory-mapped, so: 1) There are no dedicated (fast-path) I/O instructions -- load and store is all you get.
For example see here for an example of accessing the RPi GPIO pins using memory mapping. Well, I'll ask on the FB forums, there are people there who care about that.
Anyway, just comment out that assembly. If you look at rtlib/android/sys_portio.c you'll see the functions throw errors.
S'orlok Reaves (talk): Just adding this brief tidbit; the Android-compiled version has:
arm-linux-androideabi-gcc -DENABLE_MT -Wall -Werror-implicit-function-declaration -DDISABLE_FFI -DDISABLE_X11 -DDISABLE_NCURSES -Wfatal-errors -O2 -c src/rtlib/android/sys_portio.c -o src/rtlib/arm-linux-androideabi-objmt/sys_portio.o
...which contains:
int fb_hIn( unsigned short port ) {
return fb_ErrorSetNum( FB_RTERROR_ILLEGALFUNCTIONCALL );
}
...etc. I'm sure you (TMC) know about this; I'm just adding it for clarity's sake to anyone else reading along.
No time to work on this today, but I'll probably use FB_RTERROR_ILLEGALFUNCTIONCALL in the linux/sys_portio.c when I get a chance.
Edit: Whoops, I should really read the Talk page before posting; the previous post by TMC already has all of this. Thanks for the link on I/O mapping; it's informative!
S'orlok Reaves (talk): Ok, using FB_RTERROR... I can get Free Basic to compile and install. Now I'm on to compiling GAME. One problem that keeps coming up is an error similar to the following:
/home/sethhetu/opt/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.7.3/../../../../arm-unknown-linux-gnueabi/bin/ld: warning: libpulse-simple.so.0, needed by /home/sethhetu/opt/rpi_sync/usr/lib/arm-linux-gnueabihf/libSDL.so, not found (try using -rpath or -rpath-link)
This is annoying, because I have libpulse-simple.so.0, and I have "-L/home/sethhetu/opt/rpi_sync/usr/lib/arm-linux-gnueabihf" in my C/CXXFLAGS. I tried adding this to SConscript:
LDFLAGS = '-rpath-link="/home/sethhetu/opt/rpi_sync/usr/lib/arm-linux-gnueabihf"'
..but it doesn't seem to help. Right now, I am simply adding every library manually to, e.g., SDL's list:
'sdl':
{'shared_modules': 'music_sdl.bas sdl_lumprwops.bas',
'libraries': 'SDL SDL_mixer asound pulse-simple pulse directfb fusion direct caca ts mikmod vorbisfile vorbis FLAC'}
Any ideas on getting this working would be very helpful.
Edit: But don't think too hard; I'm probably just going to chroot my way around this problem regardless
TMC (talk): Did you add "-L/home/sethhetu/opt/rpi_sync/usr/lib/arm-linux-gnueabihf" to C/CXXFLAGS, or to CXXLINKFLAGS? You should add it to the later (in SConscript), that's what's actually used. And that really ought to be changed to LDFLAGS instead. (SConscript's philosophy is to ignore the environment that scons is invoked in in order to not depend on it, so generally our build script ignores env variables too.)
Other than that, I actually don't really know much about all of that, and just fiddle with things until they work.
S'orlok Reaves (talk): I've tried each of those, and it doesn't help (thanks though). I'm in the middle of preparing a chroot for this (it's unrelated; I'm getting hard-includes to "/lib" and "/usr" as top-levels, so I figure a chroot is the only way to go). I'll post back with more results later.
First Successful Build with RPi[edit]
S'orlok Reaves (talk): Don't get too excited; graphics don't work. But here's how I got it to compile.
First, make a directory like so:
mkdir ~/rpi_sync export RPI_HOME=/home/YOU/rpi_sync
We'll do everything in this directory, so it should be relatively sane.
Now, connect to your Pi and yank some stuff. The IP address will change, of course.
cd $RPI_HOME rsync -rl pi@192.168.1.5:/usr . rsync -rl pi@192.168.1.5:/lib .
So now "lib" and "usr" are copies of the Pi's. We need two more directories; one for our source and one for installed cross-compiling tools (fbc and gcc).
cd $RPI_HOME mkdir source mkdir opt
Let's make our compiler. We are using crosstool-ng, since it's the most common option. Follow this page:
http://www.kitware.com/blog/home/post/426
...except for the "prefix directory" choose:
${RPI_HOME}/opt/${CT_TARGET}.
In order to make the setting of environment variables slightly less painful, I've made a simple "wish-list", called "set_vars.source". You should copy/save this file to your $RPI_HOME directory:
http://pastie.org/8076443
From now on, when you open a terminal for compiling, do the following:
cd $RPI_HOME source set_vars.source
Now we need FreeBasic. Get the source:
cd $RPI_HOME/source git clone git://git.code.sf.net/u/teeemcee/fbc freebasic
You'll need to mangle things a bit. Open "freebasic/src/rtlib/linux/sys_portio.c", and change it to look like this:
/* ports I/O functions */
#include "../fb.h"
#include "../unix/fb_private_console.h"
int fb_hIn( unsigned short port ) {
return fb_ErrorSetNum( FB_RTERROR_ILLEGALFUNCTIONCALL );
}
int fb_hOut( unsigned short port, unsigned char value ) {
return fb_ErrorSetNum( FB_RTERROR_ILLEGALFUNCTIONCALL );
}
Now, create a file called "config.mk" in the "freebasic" directory and give it the following contents:
ENABLE_PREFIX=1
prefix=${RPI_HOME}/opt/fbc-0.90-android
V=1
Note: I know "android" is wrong here, but it's just a visual error, and I don't want to go scouring my ENV.
Now, compile and install Freebasic as explained in the main page:
make compiler make rtlib TARGET=arm-unknown-linux-gnueabi make install-compiler install-rtlib install-includes
We're ready to compile the OHR's source. Grab it:
cd $RPI_HOME/source svn co https://rpg.hamsterrepublic.com/source ohrrpgce
We need to change a few things. Open "ohrrpgce/wip/SConscript" and replace its text with the following:
http://pastie.org/8076462
Note: These changes are not the most elegant, and I would not recommend merging them. Essentially, they are all of the "arm+linux instead of arm+android" variety.
There's one more thing you need to do, and it's ugly:
sudo mkdir /lib/arm-linux-gnueabihf
sudo ln -s ${RPI_HOME}/lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 /lib/arm-linux-gnueabihf
sudo ln -s ${RPI_HOME}/lib/arm-linux-gnueabihf/libc.so.6 /lib/arm-linux-gnueabihf
sudo ln -s ${RPI_HOME}/lib/arm-linux-gnueabihf/libpthread.so.0 /lib/arm-linux-gnueabihf
sudo mkdir /usr/lib/arm-linux-gnueabihf
sudo ln -s ${RPI_HOME}/usr/lib/arm-linux-gnueabihf/libc_nonshared.a /usr/lib/arm-linux-gnueabihf
sudo ln -s ${RPI_HOME}/usr/lib/arm-linux-gnueabihf/libpthread_nonshared.a /usr/lib/arm-linux-gnueabihf
This probably won't mess up your system, since your compiler will never look in "arm-linux-gnueabihf" for libraries. Anyway, I don't know what's considered the "right" way to handle this.
Now, build it:
cd $RPI_HOME/source/ohrrpgce/wip scons fbc=$FBC rpi=1 debug=1 game
Et voila!
Of course it doesn't actually work; here's an strace:
http://pastebin.com/bp8nND16
...and an latrace:
http://pastebin.com/N1GjRt0E
More debugging to follow.
S'orlok Reaves (talk): If you use this Sconscript, it'll work: http://pastie.org/8077124
James trying to get android fbc 1.06 working[edit]
Bob the Hamster (talk) 13:23, 12 September 2016 (PDT): So I initially skipped the part about installing a "toolchain" since it said it was optional, and I had never doen it previously (I think I was using a pre-built fbc-arm that you gave me TMC, I don't think I have ever compiled it myself)
But the config.mk file seems to require a toolchain, so I went to install it. I followed the same method used by wip/android/compile-using-toolchain.sh but it fails saying:
Auto-config: --toolchain=arm-linux-androideabi-4.6 Toolchain /home/james/misc/android-ndk-r8d/toolchains/arm-linux-androideabi-4.6/prebuilt//bin/arm-linux-androideabi-gcc is missing!
And indeed, that folder does not exist. The topmost part of that path that exists is: /home/james/misc/android-ndk-r8d/toolchains/arm-linux-androideabi-4.6/prebuilt/ and the only folder inside it is linux-x86
TMC (talk) 21:51, 12 September 2016 (PDT): That shows that your NDK is built for 32 bit rather than 64 bit linux. compile-using-toolchain.sh explicitly requests HOST=linux-x86_64, but there really is no good reason for it to, so you can change that part.
Anyway, you're right, you don't need a standalone toolchain. In your case, just put /home/james/misc/android-ndk-r8d/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/ in your PATH before invoking make or scons.
Bob the Hamster (talk) 10:36, 13 September 2016 (PDT): Okay, I am trying again with the updated instructions... however, I don't think I am actually compiling an arm build of freebasic:
/home/james/misc/fbc-1.06-android/bin/fbc -c build/bmod.rbas.bas -o build/bmod.rbas.o -mt -r -d __FB_ANDROID__=1 -O 2 -gen gcc -arch arm -R -d IS_GAME -m game error 80: Invalid command-line option, "-arch arm"
My config.mk looks like:
CFLAGS := -Wfatal-errors -g FBCFLAGS := -g FBLFLAGS := -g prefix=$(HOME)/misc/fbc-1.06-android
And I had already set export PATH=$PATH:/home/james/misc/android-ndk-r8d/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/
TMC (talk) 18:30, 13 September 2016 (PDT): OK, my fault, I needed to push some changes to scons. I pushed the minimal changes rather than my incomplete rewrite of android/crosscompiling stuff, which could break things again...
Thinking more about it, if you are just creating an .apk rather than compiling commandline programs, you actually don't ever need to put the toolchain in your PATH (not when compiling fbc, running scons, or running build.sh), build.sh just needs the NDK in your path.
You're not compiling a copy of FB that targets arm. FB doesn't have special crosscompiling builds, it has a single universal fbc executable per host plus libraries for zero or more targets, with the target selected by "-target" and "-arch", so there's no need to have separate fbc builds for android and linux. If you run "make all install", then it'll install libraries for the default target (your own system, probably linux-x86_64 rather than linux-x86).
Anyway, just to be sure I tried running autotest.rpg in an emulator, which I've done several times recently without problems, but this time when cleaning up after succeeding it showed an error about not being able to clean up:
I/OHRRPGCE( 757): ! TRACE: TESTS SUCCEEDED I/OHRRPGCE( 757): ...Quit the game. I/OHRRPGCE( 757): ! days_since_datestr: bad datestr ??�#-- I/OHRRPGCE( 757): Ignore ??�# because it has only been dead 0 days I/OHRRPGCE( 757): Deleting tmpdir /data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp/ I/OHRRPGCE( 757): ! Could not remove(/data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp//??�3???): No such file or directory I/OHRRPGCE( 757): ! Could not remove(/data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp//??�#): No such file or directory I/OHRRPGCE( 757): ! Could not remove(/data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp//??�#): No such file or directory I/OHRRPGCE( 757): ! Could not remove(/data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp//??�#): No such file or directory I/OHRRPGCE( 757): ! Could not remove(/data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp//??�3?): No such file or directory I/OHRRPGCE( 757): ! Could not remove(/data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp//??�#): No such file or directory I/OHRRPGCE( 757): ! Could not remove(/data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp//??�#): No such file or directory I/OHRRPGCE( 757): ! Could not remove(/data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp//??�#): No such file or directory I/OHRRPGCE( 757): ! Could not remove(/data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp//??�+???9): No such file or directory ... I/OHRRPGCE( 757): ! ERROR: killdir: refusing to delete directory '/data/data/com.hamsterrepublic.ohrrpgce.game/files/.ohrrpgce/ohrrpgce20160914005817.759.tmp//??��???' ... F/libc ( 757): @@@ ABORTING: LIBC: ARGUMENT IS INVALID HEAP ADDRESS IN dlfree addr=0x2a0368a0
Looks like memory corruption caused all of that. Surprisingly the program didn't crash; I had to use ndk-gdb to kill it. I ran again and it happened again. I don't know what's changed!
TMC (talk) 19:45, 13 September 2016 (PDT): OK, I worked out the problem, it was compiling without __FB_ANDROID__ defined. Committing a fix.
Bob the Hamster (talk) 07:21, 14 September 2016 (PDT): Hmmm... even with your fix, it is still failing like this: http://pastebin.com/raw/9x4dZT52 it says that -target android is not recognized. Is there a way to ask fbc to list which targets and archs are available?
TMC (talk) 08:38, 14 September 2016 (PDT): I think you're on the wrong git branch. I see I forgot to specify that in the instructions... checkout my android branch (e.g. git checkout origin/android if you cloned from my repo), and rerun make -j4 compiler install-compiler install-includes
Bob the Hamster (talk) 09:40, 14 September 2016 (PDT): Beautiful! That was it! I am compiling fine now, and my apks seem to be working fine.
I also checked my adb logcat for any corrupt temp file names like the ones you saw in cleanup, but apparently that didn't happen on my device.
TMC (talk) 07:11, 15 September 2016 (PDT): That's a relief!
That corruption I got resulted in a visible error. I think it happened because of the call to mbstowcs in decode_filename in util.bas, which isn't supported on android.
