Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2012-12

Building the Android branch

28 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Sven Barth

Hello together!

I'm currently testing the Android branch and I've already reached a problem when trying to build it. I've downloaded the current Android NDK r8c and then tried to run the following command line:

make all OS_TARGET=android CPU_TARGET=arm
CROSSBINDIR=/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin BINUTILSPREFIX=arm-linux-androideabi- OPT=-dFPC_ARMEL CROSSOPT="-CpARMv6 -Cfsoft"

This works until the process reaches the CHM package where it wants to compile chmls. The compiler then returns with a linker error when executing the following command (reported by fpmake):

/mnt/data/source/fpc/fpc-android/compiler/ppcrossarm -Tandroid -FEchm/bin/arm-android -FUchm/units/arm-android
-Fu/mnt/data/source/fpc/fpc-android/rtl/units/arm-android -Fu/mnt/data/source/fpc/fpc-android/packages/fcl-xml/units/arm-android -Fu/mnt/data/source/fpc/fpc-android/packages/fcl-base/units/arm-android -Tandroid -Parm -XParm-linux-androideabi- -Xr -Ur -Xs -O2 -n -Fu/mnt/data/source/fpc/fpc-android/rtl/units/arm-android -FD/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin -dFPC_ARMEL -darm -dRELEASE -CpARMv6 -Cfsoft -viq chm/src/chmls.lpr

When I run that command manually from within the packages directory I get the following output:

=== output begin ===

(1002) Target OS: Android for ARMEL
(3104) Compiling chm/src/chmls.lpr
(9009) Assembling chmls
(9015) Linking chm/bin/arm-android/chmls
/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:1:22: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:2:67: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:3:40: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:4:41: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:5:54: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:47:13: ignoring command OPTION; OPTION is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:52:29: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:52:50: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:52:75: ignoring SEARCH_DIR; SEARCH_DIR is only valid for scripts specified via -T/--script /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/chmls.o
/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/chmreader.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/chmbase.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/chmsitemap.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-base/units/arm-android/contnrs.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/paslzx.o
/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/chmfiftimain.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/htmlindexer.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/fasthtmlparser.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-base/units/arm-android/avl_tree.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/htmlutil.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find chm/units/arm-android/chmtypes.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-xml/units/arm-android/xmlcfg.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-xml/units/arm-android/dom.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-xml/units/arm-android/xmlread.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-xml/units/arm-android/xmlwrite.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-xml/units/arm-android/xmlutils.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-xml/units/arm-android/dtdmodel.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-base/units/arm-android/uriparser.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-xml/units/arm-android/xmlreader.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: error: cannot find ./fcl-xml/units/arm-android/xmltextreader.o /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/prt0.o:(.text+0x40): error: undefined reference to 'PASCALMAIN'
chmls.lpr(629) Error: (9013) Error while linking
chmls.lpr(629) Fatal: (10026) There were 1 errors compiling module, stopping Fatal: (1018) Compilation aborted

=== output end ===

The files mentioned in the output as "not found" do indeed exist.

Just in case the beginning of the generated link.res file looks like this:

=== link.res begin ===

SEARCH_DIR(./chm/src/)
SEARCH_DIR(/mnt/data/source/fpc/fpc-android/rtl/units/arm-android/) SEARCH_DIR(./fcl-xml/units/arm-android/)
SEARCH_DIR(./fcl-base/units/arm-android/)
SEARCH_DIR(/mnt/data/source/fpc/fpc-android/compiler/) INPUT(
/mnt/data/source/fpc/fpc-android/rtl/units/arm-android/prt0.o chm/units/arm-android/chmls.o
/mnt/data/source/fpc/fpc-android/rtl/units/arm-android/system.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/objpas.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/classes.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/getopts.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/sysutils.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/types.o chm/units/arm-android/chmreader.o
chm/units/arm-android/chmbase.o
chm/units/arm-android/chmsitemap.o
/mnt/data/source/fpc/fpc-android/rtl/units/arm-android/typinfo.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/rtlconsts.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/unix.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/errors.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/sysconst.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/unixtype.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/baseunix.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/unixutil.o /mnt/data/source/fpc/fpc-android/rtl/units/arm-android/syscall.o ./fcl-base/units/arm-android/contnrs.o
chm/units/arm-android/paslzx.o
chm/units/arm-android/chmfiftimain.o
chm/units/arm-android/htmlindexer.o
chm/units/arm-android/fasthtmlparser.o
./fcl-base/units/arm-android/avl_tree.o
/mnt/data/source/fpc/fpc-android/rtl/units/arm-android/math.o chm/units/arm-android/htmlutil.o
/mnt/data/source/fpc/fpc-android/rtl/units/arm-android/strutils.o chm/units/arm-android/chmtypes.o
./fcl-xml/units/arm-android/xmlcfg.o
./fcl-xml/units/arm-android/dom.o
./fcl-xml/units/arm-android/xmlread.o
./fcl-xml/units/arm-android/xmlwrite.o
./fcl-xml/units/arm-android/xmlutils.o
./fcl-xml/units/arm-android/dtdmodel.o
./fcl-base/units/arm-android/uriparser.o
./fcl-xml/units/arm-android/xmlreader.o
./fcl-xml/units/arm-android/xmltextreader.o
)
ENTRY(_start)
/* Script for -z combreloc: combine and sort reloc sections */ OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm",
"elf32-littlearm")
OUTPUT_ARCH(arm)
SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib"); SECTIONS
{
...

=== link.res end ===

Am I doing something wrong here or is the compiler the culprit?

Regards,
Sven

Reply by email

Thomas Schatzl
to Sven Barth

Hi,

Sven Barth wrote 20 lines
Hello together! I'm currently testing the Android branch and I've already reached a problem when trying to build it. I've downloaded the current Android NDK r8c and then tried to run the following command line: make all OS_TARGET=android CPU_TARGET=arm CROSSBINDIR=/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin BINUTILSPREFIX=arm-linux-androideabi- OPT=-dFPC_ARMEL CROSSOPT="-CpARMv6 -Cfsoft" This works until the process reaches the CHM package where it wants to compile chmls. The compiler then returns with a linker error when executing the following command (reported by fpmake): /mnt/data/source/fpc/fpc-android/compiler/ppcrossarm -Tandroid [...] /mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld: warning: chm/bin/arm-android/link.res:1:22: ignoring SEARCH_DIR; [...]

The problem is that the android 8c ndk uses the GOLD linker by default. GOLD is not compatible with fpc.

E.g.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620815

Can you retry with an older ndk (GOLD is new to the 8c ndk). Alternatively, in <ndk-dir>/[...]/arm-linux-androideabi-4.6/prebuilt/ arm-linux-androideabi-ld there is a copy of the
arm-linux-androideabi-ld.gold executable. There is an arm-linux-androideabi-ld.bfd there as well, so just overwrite arm-linux-androideabi-ld with the latter (or symlink to the bfd one).

Another thing, you need to add the platforms/android-XX/arch-arm/usr/lib directory to the library search paths using -Fl in the CROSS_OPT. Otherwise the compiler won't find the C library later.

There is a new issue I have never seen before that fpdoc (actually cwstring) now wants to link with libiconv which is not available on Android (you can build it yourselves though). Simply excluding it from the android build would fix that.

Maybe you could have a look?

Thomas

Reply by email

Sven Barth
to Thomas Schatzl
Thomas Schatzl wrote 11 lines
Hi, On Mon, 2012-12-17 at 21:45 +0100, Sven Barth wrote: > Hello together! > > I'm currently testing the Android branch and I've already reached a > problem when trying to build it. I've downloaded the current Android NDK > r8c and then tried to run the following command line: > > make all OS_TARGET=android CPU_TARGET=arm >

CROSSBINDIR=/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin

Show quoted text 10 lines
> BINUTILSPREFIX=arm-linux-androideabi- OPT=-dFPC_ARMEL CROSSOPT="-CpARMv6 > -Cfsoft" > > This works until the process reaches the CHM package where it wants to > compile chmls. The compiler then returns with a linker error when > executing the following command (reported by fpmake): > > /mnt/data/source/fpc/fpc-android/compiler/ppcrossarm -Tandroid > [...] >

/mnt/data/downloads/dev/android/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-ld:

Show quoted text 16 lines
> warning: chm/bin/arm-android/link.res:1:22: ignoring SEARCH_DIR; > [...] The problem is that the android 8c ndk uses the GOLD linker by default. GOLD is not compatible with fpc. E.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620815 Can you retry with an older ndk (GOLD is new to the 8c ndk). Alternatively, in <ndk-dir>/[...]/arm-linux-androideabi-4.6/prebuilt/ arm-linux-androideabi-ld there is a copy of the arm-linux-androideabi-ld.gold executable. There is an arm-linux-androideabi-ld.bfd there as well, so just overwrite arm-linux-androideabi-ld with the latter (or symlink to the bfd one).

Yes, that was the problem -.-

Maybe we should somewhen investigate what it would mean to support GOLD... or we concentrate to get the internal linker for Android working :D

Another thing, you need to add the platforms/android-XX/arch-arm/usr/lib directory to the library search paths using -Fl in the CROSS_OPT. Otherwise the compiler won't find the C library later.

Correct... Done...

Show quoted text 6 lines
There is a new issue I have never seen before that fpdoc (actually cwstring) now wants to link with libiconv which is not available on Android (you can build it yourselves though). Simply excluding it from the android build would fix that. Maybe you could have a look?

Excluding fpdoc itself is a bit tricky as it's listed in the basic "dirs" of utils/Makefile.fpc and thus is built for every target for which utils is build... for me locally I just added Android to the NOUTILSTARGET of the base Makefile(.fpc).

Maybe the real solution would be the Unicode String Manager posted here: http://bugs.freepascal.org/view.php?id=22909

The discussion about it's inclusion died down after a mail was sent to the Unicode consortium where we asked about some legal issues regarding the Unicode tables... they seem to have never answered though...

So building works so far, but the next problem is "crossinstall"... even after I do a normal install for my host system I get the following when trying to do a crossinstall for Android:

=== output begin ===

make install CROSSINSTALL=1
make[1]: Entering directory `/mnt/data/source/fpc/fpc-android' make installbase
FPC=/mnt/data/source/fpc/fpc-android/compiler/ppcrossarm ZIPDESTDIR=/mnt/data/source/fpc/fpc-android FPCMAKE=fpcmake make[2]: Entering directory `/mnt/data/source/fpc/fpc-android' /usr/bin/install -m 755 -d
/mnt/data/source/fpc/fpc-android-install/lib/fpc/2.7.1 /usr/bin/install -m 755 -d /mnt/data/source/fpc/fpc-android-install/bin make compiler_install
FPC=/mnt/data/source/fpc/fpc-android/compiler/ppcrossarm ZIPDESTDIR=/mnt/data/source/fpc/fpc-android FPCMAKE=fpcmake make[3]: Entering directory `/mnt/data/source/fpc/fpc-android' make -C compiler install
make[4]: Entering directory `/mnt/data/source/fpc/fpc-android/compiler' make -C utils install
make[5]: Entering directory
`/mnt/data/source/fpc/fpc-android/compiler/utils'
make[5]: Leaving directory `/mnt/data/source/fpc/fpc-android/compiler/utils' /usr/bin/install -m 755 -d
/mnt/data/source/fpc/fpc-android-install/lib/fpc/2.7.1 /usr/bin/install -c -m 755 ppcrossarm
/mnt/data/source/fpc/fpc-android-install/lib/fpc/2.7.1/ppcrossarm make[4]: Leaving directory `/mnt/data/source/fpc/fpc-android/compiler' make[3]: Leaving directory `/mnt/data/source/fpc/fpc-android' make rtl_install
FPC=/mnt/data/source/fpc/fpc-android/compiler/ppcrossarm ZIPDESTDIR=/mnt/data/source/fpc/fpc-android FPCMAKE=fpcmake make[3]: Entering directory `/mnt/data/source/fpc/fpc-android' make -C rtl install
make[4]: Entering directory `/mnt/data/source/fpc/fpc-android/rtl' make -C android all
make[5]: Entering directory `/mnt/data/source/fpc/fpc-android/rtl/android' make[5]: Leaving directory `/mnt/data/source/fpc/fpc-android/rtl/android' fpcmake -p -Tarm-android Makefile.fpc
Processing Makefile.fpc
Error: No targets set
make[4]: *** [fpc_install] Fehler 1
make[4]: Leaving directory `/mnt/data/source/fpc/fpc-android/rtl' make[3]: *** [rtl_install] Fehler 2
make[3]: Leaving directory `/mnt/data/source/fpc/fpc-android' make[2]: *** [installbase] Fehler 2
make[2]: Leaving directory `/mnt/data/source/fpc/fpc-android' make[1]: *** [installall] Fehler 2
make[1]: Leaving directory `/mnt/data/source/fpc/fpc-android' make: *** [crossinstall] Fehler 2

=== output end ===

Regards,
Sven

PS: Sorry, Thomas, should have gone to the list as well -.-

Reply by email

Thomas Schatzl
to Sven Barth

Hi,

Sven Barth wrote 18 lines
On 18.12.2012 00:10, Thomas Schatzl wrote: > Hi, > > On Mon, 2012-12-17 at 21:45 +0100, Sven Barth wrote: >> I'm currently testing the Android branch and I've already reached a >> problem when trying to build it. I've downloaded the current Android NDK >> r8c and then tried to run the following command line: >> [...] >> > The problem is that the android 8c ndk uses the GOLD linker by default. > GOLD is not compatible with fpc. > > [...] Yes, that was the problem -.- Maybe we should somewhen investigate what it would mean to support GOLD... or we concentrate to get the internal linker for Android working :D

On i386-android I guess you can simply use the i386-linux internal linker. Not sure about how much work an arm-linux internal linker would be (if there isn't).

Show quoted text 7 lines
> There is a new issue I have never seen before that fpdoc (actually > cwstring) now wants to link with libiconv which is not available on > Android (you can build it yourselves though). Simply excluding it from > the android build would fix that. > > Maybe you could have a look?

Actually, I just tried, "make clean all crosszipinstall" works with a recent 2.7.1 snapshot except that you need to patch the "_FPC_libc_start" method in rtl/linux/i386/si_c.inc with the latest version. I.e. basically, the targetandroid branch needs merging with the latest trunk to work again.

Not sure why, but with trunk, utils won't be compiled in a crosszipinstall any more automatically. It does not make sense anyway to compile target binaries for them anyway since you're going to install on the host.

Bootstrapping with 2.6.0 not work. Don't remember exactly why, but this is just another reason then.

The missing libiconv also prevents making a zipinstall for android-arm at the moment; as mentioned, I think it did not have that problem earlier. I remember that this already worked at some point. Eventually this error slipped through when merging trunk to that branch last time.

Either disabling compilation of fpdoc or simply using the bootstrap tools on the target (fpcmake, data2inc and ppcarm compile) to complete a build on the target should be fine.

If you disable the WPO cycle on these devices, and using all threads/cores you can get, making a zipinstall does not take that long on current arm machines. Iirc the fpc arm-linux build machine (quad core, 1.4Ghz) takes around 12 minutes to generate a full snapshot (with WPO cycle). Most time is taken by the serial compiler cycle.

Show quoted text 6 lines
Maybe the real solution would be the Unicode String Manager posted here: http://bugs.freepascal.org/view.php?id=22909 The discussion about it's inclusion died down after a mail was sent to the Unicode consortium where we asked about some legal issues regarding the Unicode tables... they seem to have never answered though...

This would be a good idea, but is orthogonal to the android branch.

Show quoted text 10 lines
So building works so far, but the next problem is "crossinstall"... even after I do a normal install for my host system I get the following when trying to do a crossinstall for Android === output begin === [...]make[5]: Leaving directory `/mnt/data/source/fpc/fpc-android/rtl/android' fpcmake -p -Tarm-android Makefile.fpc Processing Makefile.fpc Error: No targets set [...]

Use of wrong fpcmake.

What I typically do, since I'm often working with different fpc versions/branches at the same time, is not have a global fpc install. I simply copy fpcmake (in utils/fpcm), data2inc (in utils) and the ppc386 bootstrap snapshot compiler into a directory and add that directory into the path.

So compile the branch once with the 2.7.1 compiler (after applying above patch, e.g. make zipinstall PP=...) to get these bootstrap tools, put those files into a directory, put that directory into the path and use them to compile the targetandroid branch.

This is of course a totally unsupported way to use fpc and you're on your own when doing so :-P ymmv.

Hth,
Thomas

Reply by email

Sven Barth
to Thomas Schatzl
Thomas Schatzl wrote 13 lines
> > There is a new issue I have never seen before that fpdoc (actually > > cwstring) now wants to link with libiconv which is not available on > > Android (you can build it yourselves though). Simply excluding it from > > the android build would fix that. > > > > Maybe you could have a look? > Actually, I just tried, "make clean all crosszipinstall" works with a recent 2.7.1 snapshot except that you need to patch the "_FPC_libc_start" method in rtl/linux/i386/si_c.inc with the latest version. I.e. basically, the targetandroid branch needs merging with the latest trunk to work again.

Or you could just merge to trunk... might result in a better test user coverage as well :)

Not sure why, but with trunk, utils won't be compiled in a crosszipinstall any more automatically. It does not make sense anyway to compile target binaries for them anyway since you're going to install on the host.

AFAIK that was disabled on purpose some time ago exactly because of that reason.

Show quoted text 25 lines
> So building works so far, but the next problem is "crossinstall"... even > after I do a normal install for my host system I get the following when > trying to do a crossinstall for Android > > === output begin === > [...]make[5]: Leaving directory `/mnt/data/source/fpc/fpc-android/rtl/android' > fpcmake -p -Tarm-android Makefile.fpc > Processing Makefile.fpc > Error: No targets set > [...] Use of wrong fpcmake. What I typically do, since I'm often working with different fpc versions/branches at the same time, is not have a global fpc install. I simply copy fpcmake (in utils/fpcm), data2inc (in utils) and the ppc386 bootstrap snapshot compiler into a directory and add that directory into the path. So compile the branch once with the 2.7.1 compiler (after applying above patch, e.g. make zipinstall PP=...) to get these bootstrap tools, put those files into a directory, put that directory into the path and use them to compile the targetandroid branch. This is of course a totally unsupported way to use fpc and you're on your own when doing so :-P ymmv.

I now simply replaced my 2.6.0 fpcmake with one compiled from the Android branch and were happy to go :)

So I (this time on Windows) managed to compile and install the branch and now just need to check whether it will work...

Now I just need to test whether the Android LCL test application/library works... Thank you so far :D

Regards,
Sven

Reply by email

Thomas Schatzl
to Sven Barth

Hi,

On Tue, 2012-12-18 at 13:48 +0100, Sven Barth wrote:

Thomas Schatzl wrote 20 lines
> >> > There is a new issue I have never seen before that fpdoc >> > (actually >> > cwstring) now wants to link with libiconv which is not >> > available on >> > Android (you can build it yourselves though). Simply excluding >> > it from >> > the android build would fix that. >> > >> > Maybe you could have a look? >> > Actually, I just tried, "make clean all crosszipinstall" works with > a > recent 2.7.1 snapshot except that you need to patch the > "_FPC_libc_start" method in rtl/linux/i386/si_c.inc with the latest > version. I.e. basically, the targetandroid branch needs merging with > the latest trunk to work again. Or you could just merge to trunk... might result in a better test user coverage as well :)

:) Maybe I have time to clean up and propose a patch in January.

Show quoted text 9 lines
I now simply replaced my 2.6.0 fpcmake with one compiled from the Android branch and were happy to go :) So I (this time on Windows) managed to compile and install the branch and now just need to check whether it will work... Now I just need to test whether the Android LCL test application/library works... Thank you so far :D

I never tried the LCL, but with some hacking of android makefiles I managed to create and run some opengl demo application. Use the NDK bindings on lazarus-ccr; just looked, the bindings are still there, but that example application seems to be gone.

I heard other people were successful with a hacked arm/linux compiler before that branch started.

Of course, console apps like the compiler to do e.g. a make cycle also worked last time I tried.

Thomas

Reply by email

Sven Barth
to Thomas Schatzl
Thomas Schatzl wrote 20 lines
> I now simply replaced my 2.6.0 fpcmake with one compiled from the > Android branch and were happy to go :) > > So I (this time on Windows) managed to compile and install the branch > and now just need to check whether it will work... > > Now I just need to test whether the Android LCL test > application/library works... Thank you so far :D > I never tried the LCL, but with some hacking of android makefiles I managed to create and run some opengl demo application. Use the NDK bindings on lazarus-ccr; just looked, the bindings are still there, but that example application seems to be gone. I heard other people were successful with a hacked arm/linux compiler before that branch started. Of course, console apps like the compiler to do e.g. a make cycle also worked last time I tried.

I successfully compiled the lcl-customdrawn example library, but the Java side code does not like the idea of being compiled -.- I'll need to look into this...

Regards,
Sven

Reply by email

Sven Barth
to Sven Barth
Sven Barth wrote 24 lines
Am 18.12.2012 14:15, schrieb Thomas Schatzl: > >> I now simply replaced my 2.6.0 fpcmake with one compiled from the >> Android branch and were happy to go :) >> >> So I (this time on Windows) managed to compile and install the branch >> and now just need to check whether it will work... >> >> Now I just need to test whether the Android LCL test >> application/library works... Thank you so far :D >> > I never tried the LCL, but with some hacking of android makefiles I > managed to create and run some opengl demo application. Use the NDK > bindings on lazarus-ccr; just looked, the bindings are still there, but > that example application seems to be gone. > > I heard other people were successful with a hacked arm/linux compiler > before that branch started. > > Of course, console apps like the compiler to do e.g. a make cycle also > worked last time I tried. I successfully compiled the lcl-customdrawn example library, but the Java side code does not like the idea of being compiled -.- I'll need to look into this...

Ok, the problem with the Java side code was that I didn't have the corresponding Java API installed (version 8)...

Now I can build the package, but I get a link error from Android. Looking at the output of objdump I can't mind that it has problems:

=== objdump begin ===

D:\lazarus\1.0\examples\androidlcl\android\libs\armeabi\liblclapp.so: file format elf32-littlearm

Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**15 filesz 0x00425dc0 memsz 0x00425dc0 flags r-x
LOAD off 0x00428000 vaddr 0x00428000 paddr 0x00428000 align 2**15 filesz 0x0001f9c8 memsz 0x00033a28 flags rw-
DYNAMIC off 0x00428000 vaddr 0x00428000 paddr 0x00428000 align 2**2 filesz 0x000000c8 memsz 0x000000c8 flags rw-
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 filesz 0x00000000 memsz 0x00000000 flags rwx

Dynamic Section:
NEEDED
D:\Android\android-ndk-r8c\platforms\android-8\arch-arm\usr\lib\\libdl.so NEEDED libjnigraphics.so
NEEDED liblog.so
SONAME liblclapp.so
INIT 0x000beea4
FINI 0x000e069c
HASH 0x000000b4
STRTAB 0x0000021c
SYMTAB 0x0000010c
STRSZ 0x000002a8
SYMENT 0x00000010
PLTGOT 0x004280c8
PLTRELSZ 0x00000018
PLTREL 0x00000011
JMPREL 0x000bee54
REL 0x000004c4
RELSZ 0x000be990
RELENT 0x00000008
TEXTREL 0x00000000
RELCOUNT 0x00017d32
private flags = 5000002: [Version5 EABI] [has entry point]

=== objdump end ===

The first one shouldn't be the full pathname... also isn't the linker on Android called "/system/bin/linker"?

Do I need any further options besides the -Xp..., -FD..., -Fl..., -CpARMv6 and -CfSoft to build a library?

Regards,
Sven

Reply by email

Sven Barth
to Sven Barth
Sven Barth wrote 77 lines
Am 18.12.2012 14:22, schrieb Sven Barth: > Am 18.12.2012 14:15, schrieb Thomas Schatzl: >> >>> I now simply replaced my 2.6.0 fpcmake with one compiled from the >>> Android branch and were happy to go :) >>> >>> So I (this time on Windows) managed to compile and install the branch >>> and now just need to check whether it will work... >>> >>> Now I just need to test whether the Android LCL test >>> application/library works... Thank you so far :D >>> >> I never tried the LCL, but with some hacking of android makefiles I >> managed to create and run some opengl demo application. Use the NDK >> bindings on lazarus-ccr; just looked, the bindings are still there, but >> that example application seems to be gone. >> >> I heard other people were successful with a hacked arm/linux compiler >> before that branch started. >> >> Of course, console apps like the compiler to do e.g. a make cycle also >> worked last time I tried. > I successfully compiled the lcl-customdrawn example library, but the > Java side code does not like the idea of being compiled -.- I'll need > to look into this... Ok, the problem with the Java side code was that I didn't have the corresponding Java API installed (version 8)... Now I can build the package, but I get a link error from Android. Looking at the output of objdump I can't mind that it has problems: === objdump begin === D:\lazarus\1.0\examples\androidlcl\android\libs\armeabi\liblclapp.so: file format elf32-littlearm Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**15 filesz 0x00425dc0 memsz 0x00425dc0 flags r-x LOAD off 0x00428000 vaddr 0x00428000 paddr 0x00428000 align 2**15 filesz 0x0001f9c8 memsz 0x00033a28 flags rw- DYNAMIC off 0x00428000 vaddr 0x00428000 paddr 0x00428000 align 2**2 filesz 0x000000c8 memsz 0x000000c8 flags rw- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 filesz 0x00000000 memsz 0x00000000 flags rwx Dynamic Section: NEEDED D:\Android\android-ndk-r8c\platforms\android-8\arch-arm\usr\lib\\libdl.so NEEDED libjnigraphics.so NEEDED liblog.so SONAME liblclapp.so INIT 0x000beea4 FINI 0x000e069c HASH 0x000000b4 STRTAB 0x0000021c SYMTAB 0x0000010c STRSZ 0x000002a8 SYMENT 0x00000010 PLTGOT 0x004280c8 PLTRELSZ 0x00000018 PLTREL 0x00000011 JMPREL 0x000bee54 REL 0x000004c4 RELSZ 0x000be990 RELENT 0x00000008 TEXTREL 0x00000000 RELCOUNT 0x00017d32 private flags = 5000002: [Version5 EABI] [has entry point] === objdump end === The first one shouldn't be the full pathname... also isn't the linker on Android called "/system/bin/linker"? Do I need any further options besides the -Xp..., -FD..., -Fl..., -CpARMv6 and -CfSoft to build a library?

Ok... first: it was a stray "-FLlibdl.so" from a former test with non working binutils.

When I remove it the library can't be linked though...

The following options are set in fpc.cfg for Android:

-XParm-linux-androideabi-
-FDD:\Android\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin -FlD:\Android\android-ndk-r8c\platforms\android-8\arch-arm\usr\lib\

The following arguments are added by Lazarus (the last three were already part of the project - removing -Xd does also not change anything):

-MObjFPC -Scghi -O1 -Tandroid -Parm -Xs -XX -vewnhi -l -Filib\arm-android -Fu..\..\lcl\units\arm-android\customdrawn -Fu..\..\lcl\units\arm-android
-Fu..\..\components\lazutils\lib\arm-android
-Fu..\..\packager\units\arm-android -Fu. -FUlib\arm-android\ -FEandroid\libs\armeabi\ -oliblclapp.so -dLCL -dLCLcustomdrawn -dANDROID -Xd -CpARMV6

Regards,
Sven

Reply by email

Thomas Schatzl
to Sven Barth

Hi,

Sven Barth wrote
> === objdump end === > > The first one shouldn't be the full pathname... also isn't the linker > on Android called "/system/bin/linker"?

You're trying to generate an executable or a shared library (.so)?

Show quoted text 5 lines
> > Do I need any further options besides the -Xp..., -FD..., -Fl..., > -CpARMv6 and -CfSoft to build a library? Ok... first: it was a stray "-FLlibdl.so" from a former test with non working binutils.

You mean the one with the full path has been added in error?

When I remove it the library can't be linked though...

What is "it" exactly? Which library cannot be linked? What's the error?

Just checked, for libraries "/system/bin/linker" should be added automatically (compiler/systems/t_android.pas)

Show quoted text 16 lines
The following options are set in fpc.cfg for Android: -XParm-linux-androideabi- -FDD:\Android\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin -FlD:\Android\android-ndk-r8c\platforms\android-8\arch-arm\usr\lib\ The following arguments are added by Lazarus (the last three were already part of the project - removing -Xd does also not change anything): -MObjFPC -Scghi -O1 -Tandroid -Parm -Xs -XX -vewnhi -l -Filib\arm-android -Fu..\..\lcl\units\arm-android\customdrawn -Fu..\..\lcl\units\arm-android -Fu..\..\components\lazutils\lib\arm-android -Fu..\..\packager\units\arm-android -Fu. -FUlib\arm-android\ -FEandroid\libs\armeabi\ -oliblclapp.so -dLCL -dLCLcustomdrawn -dANDROID -Xd -CpARMV6

Looks okay, but I will see if I can find these tests I was mentioning. That stuff is on a different computer though.

Looking through compiler/systems/t_android.pas, you may want to try commmenting line 343, the one that adds info.Dynamiclinker to the input files. Looks wrong.
(system/bin/linker is passed to ld later as --dynamic-linker option later anyway).

Thomas

Reply by email

Sven Barth
to Thomas Schatzl
"Thomas Schatzl" wrote 11 lines
Hi, On Tue, 2012-12-18 at 17:35 +0100, Sven Barth wrote: > > === objdump end === > > > > The first one shouldn't be the full pathname... also isn't the linker > > on Android called "/system/bin/linker"? You're trying to generate an executable or a shared library (.so)?

A shared library as this is what's needed for usage of the LCL. See also examples/androidlcl of a current Lazarus version (at least 1.0).

Show quoted text 7 lines
> > > > Do I need any further options besides the -Xp..., -FD..., -Fl..., > > -CpARMv6 and -CfSoft to build a library? > Ok... first: it was a stray "-FLlibdl.so" from a former test with non > working binutils. You mean the one with the full path has been added in error?

Yes. The binutils with version 2.19 crashed without reasons and on the Lazarus forum there were suggestions to add "-FLlibdl.so". I had added that to the fpc.cfg and forgot to remove it when I cleanly rebuild with the 2.21 binutils. This was all before I started to write you.

> When I remove it the library can't be linked though... What is "it" exactly? Which library cannot be linked? What's the error?

"it" was the "-FLlibdl.so" and "the library" is the one I'm trying to build. Sorry for the confusion.

Show quoted text 7 lines
Just checked, for libraries "/system/bin/linker" should be added automatically (compiler/systems/t_android.pas) > The following options are set in fpc.cfg for Android: > > -XParm-linux-androideabi- >

-FDD:\Android\android-ndk-r8c\toolchains\arm-linux-androideabi-4.6\prebuilt\windows\bin

> -FlD:\Android\android-ndk-r8c\platforms\android-8\arch-arm\usr\lib\ > > The following arguments are added by Lazarus (the last three were > already part of the project - removing -Xd does also not change

anything):

Show quoted text 17 lines
> > -MObjFPC -Scghi -O1 -Tandroid -Parm -Xs -XX -vewnhi -l > -Filib\arm-android -Fu..\..\lcl\units\arm-android\customdrawn > -Fu..\..\lcl\units\arm-android > -Fu..\..\components\lazutils\lib\arm-android > -Fu..\..\packager\units\arm-android -Fu. -FUlib\arm-android\ > -FEandroid\libs\armeabi\ -oliblclapp.so -dLCL -dLCLcustomdrawn -dANDROID > -Xd -CpARMV6 Looks okay, but I will see if I can find these tests I was mentioning. That stuff is on a different computer though. Looking through compiler/systems/t_android.pas, you may want to try commmenting line 343, the one that adds info.Dynamiclinker to the input files. Looks wrong. (system/bin/linker is passed to ld later as --dynamic-linker option later anyway).

I will try that.

Regards,
Sven

Reply by email

Sven Barth
to Thomas Schatzl: You're trying to generate an executable or a shared library (.so)? You mean the one with…
Thomas Schatzl wrote
Looking through compiler/systems/t_android.pas, you may want to try commmenting line 343, the one that adds info.Dynamiclinker to the input files. Looks wrong. (system/bin/linker is passed to ld later as --dynamic-linker option later anyway).

Ok... by removing the addition of the dynamic linker I can successfully compile and link the DLL, but when starting it I get an illegal instruction error... I have not yet tested whether this can be reproduced with an empty library as well.

=== logcat begin ===

I/lclapp ( 269): Trying to load liblclapp.so
D/dalvikvm( 269): Trying to load lib
/data/data/com.pascal.lcltest/lib/liblclapp.so 0x45f3d248 I/DEBUG ( 31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 31): Build fingerprint:
'generic/sdk/generic/:2.2/FRF91/43546:eng/test-keys' I/DEBUG ( 31): pid: 269, tid: 269 >>> com.pascal.lcltest <<< I/DEBUG ( 31): signal 4 (SIGILL), fault addr 810c9754 I/DEBUG ( 31): r0 4395408c r1 00000000 r2 bedbf670 r3 8144864c I/DEBUG ( 31): r4 00000038 r5 00000008 r6 b001037c r7 00000000 I/DEBUG ( 31): r8 80813b00 r9 0000ccb0 10 4208bc38 fp bedbf744 I/DEBUG ( 31): ip 8144864c sp bedbf668 lr 8114e29c pc 810c9754 cpsr 60000010
I/DEBUG ( 31): #00 pc 000c9754
/data/data/com.pascal.lcltest/lib/liblclapp.so
I/DEBUG ( 31): #01 lr 8114e29c
/data/data/com.pascal.lcltest/lib/liblclapp.so
I/DEBUG ( 31):
I/DEBUG ( 31): code around pc:
I/DEBUG ( 31): 810c9734 e1901f9f e2811001 e1802f91 e3520000 I/DEBUG ( 31): 810c9744 1afffffa e1a00001 e12fff1e e12fff1e I/DEBUG ( 31): 810c9754 e1902f9f e1803f91 e3530000 1afffffb I/DEBUG ( 31): 810c9764 e1a00002 e12fff1e e12fff1e e1902f9f I/DEBUG ( 31): 810c9774 e081c002 e1803f9c e3530000 1afffffa I/DEBUG ( 31):
I/DEBUG ( 31): code around lr:
I/DEBUG ( 31): 8114e27c e5810028 e59d0004 e5900028 ebfe5425 I/DEBUG ( 31): 8114e28c e59d0004 e280002c e3a01000 ebfded2d I/DEBUG ( 31): 8114e29c e59d0004 e2800030 e3a01000 ebfded29 I/DEBUG ( 31): 8114e2ac e3a03000 e3a02000 e3a01001 e3a00000 I/DEBUG ( 31): 8114e2bc ebfe53d6 e59d1004 e581000c e59d0004 I/DEBUG ( 31):
I/DEBUG ( 31): stack:
I/DEBUG ( 31): bedbf628 b001037c
I/DEBUG ( 31): bedbf62c 00000000
I/DEBUG ( 31): bedbf630 80813b00 /system/lib/libdvm.so I/DEBUG ( 31): bedbf634 810e225c
/data/data/com.pascal.lcltest/lib/liblclapp.so
I/DEBUG ( 31): bedbf638 80813b00 /system/lib/libdvm.so I/DEBUG ( 31): bedbf63c bedbf650 [stack] I/DEBUG ( 31): bedbf640 00000008
I/DEBUG ( 31): bedbf644 8136d958
/data/data/com.pascal.lcltest/lib/liblclapp.so
I/DEBUG ( 31): bedbf648 00000008
I/DEBUG ( 31): bedbf64c 810dba2c
/data/data/com.pascal.lcltest/lib/liblclapp.so
I/DEBUG ( 31): bedbf650 43954060
I/DEBUG ( 31): bedbf654 810db9ec
/data/data/com.pascal.lcltest/lib/liblclapp.so
I/DEBUG ( 31): bedbf658 00000038
I/DEBUG ( 31): bedbf65c 810e3338
/data/data/com.pascal.lcltest/lib/liblclapp.so
I/DEBUG ( 31): bedbf660 b001037c
I/DEBUG ( 31): bedbf664 8114e28c
/data/data/com.pascal.lcltest/lib/liblclapp.so
I/DEBUG ( 31): #00 bedbf668 8136d958
/data/data/com.pascal.lcltest/lib/liblclapp.so
I/DEBUG ( 31): bedbf66c 43954060
I/DEBUG ( 31): bedbf670 bedbf67c [stack] I/DEBUG ( 31): bedbf674 00000000
I/DEBUG ( 31): bedbf678 00000001
I/DEBUG ( 31): bedbf67c 00000038
I/DEBUG ( 31): bedbf680 00000008
I/DEBUG ( 31): bedbf684 b001037c
I/DEBUG ( 31): bedbf688 00000000
I/DEBUG ( 31): bedbf68c 80813b00 /system/lib/libdvm.so I/DEBUG ( 31): bedbf690 0000ccb0 [heap]
I/DEBUG ( 31): bedbf694 4208bc38
I/DEBUG ( 31): bedbf698 bedbf744 [stack] I/DEBUG ( 31): bedbf69c bedbf668 [stack] I/DEBUG ( 31): bedbf6a0 8114e25c
/data/data/com.pascal.lcltest/lib/liblclapp.so
I/DEBUG ( 31): bedbf6a4 00000000
I/DEBUG ( 31): bedbf6a8 00000000
I/DEBUG ( 31): bedbf6ac afa00304 /system/lib/liblog.so D/Zygote ( 33): Process 269 terminated by signal (4) I/ActivityManager( 59): Process com.pascal.lcltest (pid 269) has died.

=== logcat end ===

Edit: Linking with debug information I could resolve the address to InterlockedExchange. Hmm... It seems that the SDK's QEMU does not emulate a ARMv6 device?

Regards,
Sven

Reply by email

Sven Barth
to Sven Barth
Sven Barth wrote
Edit: Linking with debug information I could resolve the address to InterlockedExchange. Hmm... It seems that the SDK's QEMU does not emulate a ARMv6 device?

Running it on my own Android device does not work either, but I don't know whether it's the same error as I currently don't have access to it's log.

I seems that I'll indeed need to test a simple library first...

Regards,
Sven

Reply by email

Thomas Schatzl
to Sven Barth: Ok... by removing the addition of the dynamic linker I can successfully compile and link…

Hi,

a few notes:

Sven Barth wrote 20 lines
Am 18.12.2012 17:47, schrieb Thomas Schatzl: > Looking through compiler/systems/t_android.pas, you may want to try > commmenting line 343, the one that adds info.Dynamiclinker to the > input files. Looks wrong. (system/bin/linker is passed to ld later as > --dynamic-linker option later anyway). Ok... by removing the addition of the dynamic linker I can successfully compile and link the DLL, but when starting it I get an illegal instruction error... I have not yet tested whether this can be reproduced with an empty library as well. === logcat begin === [...] === logcat end === Edit: Linking with debug information I could resolve the address to InterlockedExchange. Hmm... It seems that the SDK's QEMU does not emulate a ARMv6 device?

- yes. See http://developer.android.com/tools/devices/emulator.html. Btw, there is not much point to compiling for armv6 for Android. The two official ABIs are either armv5te + softfloat or armv7a + vfpv3_d16 (maybe v2).
- there were lots of fixes to ARM interlocked* stuff and barriers some months ago in trunk. All these changes are not in the targetandroid branch.
- the (trunk) rtl still has some issues related to automatic detection and use of read/writebarrier code if you compile for an older cpu but run on newer. E.g. if you compile for armv5, these barriers are nops because they are not needed - but when actually running on something higher these nops are not optimal to your stuff is not threaded or you don't run on a multi-core cpu, this is not a problem.
- if you are really interested about doing Android development, I recommend getting a developer board. The emulator is really slow. Even fast developer boards are really cheap now, e.g. quad-core 1.4Ghz ARMv7 with 1GB RAM for 70 USD (www.hardkernel.com , search for Odroid-U). This device is actually pretty decent. Otherwise use an unused phone.

Thomas

Reply by email

Sven Barth
to Thomas Schatzl
Thomas Schatzl wrote 24 lines
On Wed, 2012-12-19 at 16:20 +0100, Sven Barth wrote: > Am 18.12.2012 17:47, schrieb Thomas Schatzl: >> Looking through compiler/systems/t_android.pas, you may want to try >> commmenting line 343, the one that adds info.Dynamiclinker to the >> input files. Looks wrong. (system/bin/linker is passed to ld later as >> --dynamic-linker option later anyway). > Ok... by removing the addition of the dynamic linker I can successfully > compile and link the DLL, but when starting it I get an illegal > instruction error... I have not yet tested whether this can be > reproduced with an empty library as well. > > === logcat begin === > > [...] > > === logcat end === > > Edit: Linking with debug information I could resolve the address to > InterlockedExchange. Hmm... It seems that the SDK's QEMU does not > emulate a ARMv6 device? - yes. See http://developer.android.com/tools/devices/emulator.html. Btw, there is not much point to compiling for armv6 for Android. The two official ABIs are either armv5te + softfloat or armv7a + vfpv3_d16 (maybe v2).

Then I'll need to recompile for ARMv5...

Show quoted text 5 lines
- if you are really interested about doing Android development, I recommend getting a developer board. The emulator is really slow. Even fast developer boards are really cheap now, e.g. quad-core 1.4Ghz ARMv7 with 1GB RAM for 70 USD (www.hardkernel.com , search for Odroid-U). This device is actually pretty decent. Otherwise use an unused phone.

Currently I'm mostly checking what would be necessary to get our Windows Mobile application (more or less) running on Android using LCL-CustomDrawn. For these tests the emulator and maybe my own Phone should be enough for now.

Thanks again. I'll report back if the situation improves :)

Regards,
Sven

Reply by email

Den
to Sven Barth

Hi Sven/Thomas,

I was just wondering if you guys could give me a hand as well. I'm currently interested in using the Native "targetandroid" branch. Right now I'm getting the error:

fpcmake -p -Tarm-android Makefile.fpc
Processing Makefile.fpc
Error: No targets set

This is the section of my build script:

ANDROID_LIB_DIR="$HOME/android-ndk-r8b/platforms/android-9/arch-arm/usr/lib"

export
CROSSBINDIR="$HOME/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/arm-linux-androideabi/bin" export CROSSOPT="-CfSOFT -CpARMV5 -Fl$ANDROID_LIB_DIR" export OS_TARGET="android"
export CPU_TARGET="arm"

make clean crossinstall

Is there a reason it's not using the fpcmake that has been created with crossinstall?

Any help would be greatly appreciated!
Thank you for your time!

- Dennis Fehr

Sven Barth wrote 43 lines
Am 19.12.2012 16:42, schrieb Thomas Schatzl: > On Wed, 2012-12-19 at 16:20 +0100, Sven Barth wrote: >> Am 18.12.2012 17:47, schrieb Thomas Schatzl: >>> Looking through compiler/systems/t_android.pas, you may want to try >>> commmenting line 343, the one that adds info.Dynamiclinker to the >>> input files. Looks wrong. (system/bin/linker is passed to ld later as >>> --dynamic-linker option later anyway). >> Ok... by removing the addition of the dynamic linker I can successfully >> compile and link the DLL, but when starting it I get an illegal >> instruction error... I have not yet tested whether this can be >> reproduced with an empty library as well. >> >> === logcat begin === >> >> [...] >> >> === logcat end === >> >> Edit: Linking with debug information I could resolve the address to >> InterlockedExchange. Hmm... It seems that the SDK's QEMU does not >> emulate a ARMv6 device? > - yes. See http://developer.android.com/tools/devices/emulator.html. > Btw, there is not much point to compiling for armv6 for Android. The two > official ABIs are either armv5te + softfloat or armv7a + vfpv3_d16 > (maybe v2). Then I'll need to recompile for ARMv5... > - if you are really interested about doing Android development, I > recommend getting a developer board. The emulator is really slow. Even > fast developer boards are really cheap now, e.g. quad-core 1.4Ghz ARMv7 > with 1GB RAM for 70 USD (www.hardkernel.com , search for Odroid-U). This > device is actually pretty decent. Otherwise use an unused phone. Currently I'm mostly checking what would be necessary to get our Windows Mobile application (more or less) running on Android using LCL-CustomDrawn. For these tests the emulator and maybe my own Phone should be enough for now. Thanks again. I'll report back if the situation improves :) Regards, Sven _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Den
to Sven Barth: Then I'll need to recompile for ARMv5... Currently I'm mostly checking what would be…

Hello again Sven/Thomas,

Sorry about the post again, you can ignore the previous post. I got targetandroid compiling with my buildscript.
I just had to do a make -C "$HOME/fpc-droid/utils/fpcm" before the actual make process, and setting PATH to
"$HOME/fpc-droid/utils/fpcm:$PATH" as a workaround.

I'm sure when it is merged you won't have to worry about the fpcmake as it will be aware of arm-android. I thank you very very much for starting this branch. I just wish I would've stumbled upon it sooner rather than doing it myself based on arm-linux. A quick demo works now with Android's NativeActivity. I imported Google's 'libandroid_native_app_glue.a' and the headers from the lcl/interfaces/customdrawn/android interface from Lazarus with success. I only had to change the 'ANativeActivity_onCreate' translation. Now if only you could include NativeAppGlue (record's and procedure interfaces) and the other header translations from
lcl/interfaces/customdrawn/android that would be most excellent. :)

Thank you very much again for saving me a lot of time.

- Dennis

Sven Barth wrote 43 lines
Am 19.12.2012 16:42, schrieb Thomas Schatzl: > On Wed, 2012-12-19 at 16:20 +0100, Sven Barth wrote: >> Am 18.12.2012 17:47, schrieb Thomas Schatzl: >>> Looking through compiler/systems/t_android.pas, you may want to try >>> commmenting line 343, the one that adds info.Dynamiclinker to the >>> input files. Looks wrong. (system/bin/linker is passed to ld later as >>> --dynamic-linker option later anyway). >> Ok... by removing the addition of the dynamic linker I can successfully >> compile and link the DLL, but when starting it I get an illegal >> instruction error... I have not yet tested whether this can be >> reproduced with an empty library as well. >> >> === logcat begin === >> >> [...] >> >> === logcat end === >> >> Edit: Linking with debug information I could resolve the address to >> InterlockedExchange. Hmm... It seems that the SDK's QEMU does not >> emulate a ARMv6 device? > - yes. See http://developer.android.com/tools/devices/emulator.html. > Btw, there is not much point to compiling for armv6 for Android. The two > official ABIs are either armv5te + softfloat or armv7a + vfpv3_d16 > (maybe v2). Then I'll need to recompile for ARMv5... > - if you are really interested about doing Android development, I > recommend getting a developer board. The emulator is really slow. Even > fast developer boards are really cheap now, e.g. quad-core 1.4Ghz ARMv7 > with 1GB RAM for 70 USD (www.hardkernel.com , search for Odroid-U). This > device is actually pretty decent. Otherwise use an unused phone. Currently I'm mostly checking what would be necessary to get our Windows Mobile application (more or less) running on Android using LCL-CustomDrawn. For these tests the emulator and maybe my own Phone should be enough for now. Thanks again. I'll report back if the situation improves :) Regards, Sven _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Thomas Schatzl
to Sven Barth: Then I'll need to recompile for ARMv5... Currently I'm mostly checking what would be…

Hi,

Sven Barth wrote 23 lines
Am 19.12.2012 16:42, schrieb Thomas Schatzl: > On Wed, 2012-12-19 at 16:20 +0100, Sven Barth wrote: >> Am 18.12.2012 17:47, schrieb Thomas Schatzl: >> [...] >> Hmm... It seems that the SDK's QEMU does not emulate a ARMv6 device? > > - yes. See http://developer.android.com/tools/devices/emulator.html. > Btw, there is not much point to compiling for armv6 for Android. The two > official ABIs are either armv5te + softfloat or armv7a + vfpv3_d16 > (maybe v2). Then I'll need to recompile for ARMv5... > - if you are really interested about doing Android development, I > recommend getting a developer board. The emulator is really slow. Even > fast developer boards are really cheap now, e.g. quad-core 1.4Ghz ARMv7 > with 1GB RAM for 70 USD (www.hardkernel.com , search for Odroid-U). This > device is actually pretty decent. Otherwise use an unused phone. Currently I'm mostly checking what would be necessary to get our Windows Mobile application (more or less) running on Android using LCL-CustomDrawn. For these tests the emulator and maybe my own Phone should be enough for now.

If it's only android you want to evaluate, you may want to give the i386-android target which should also work with that branch a try. This should work if you do not need OpenGLES or something hardware specific. I do not actually know, but there should be i386/android simulator images available. Performance of those should be much better. :)

Thomas

Reply by email

Sven Barth
to Thomas Schatzl
Thomas Schatzl wrote 15 lines
>> - if you are really interested about doing Android development, I >> recommend getting a developer board. The emulator is really slow. Even >> fast developer boards are really cheap now, e.g. quad-core 1.4Ghz ARMv7 >> with 1GB RAM for 70 USD (www.hardkernel.com , search for Odroid-U). This >> device is actually pretty decent. Otherwise use an unused phone. > Currently I'm mostly checking what would be necessary to get our Windows > Mobile application (more or less) running on Android using > LCL-CustomDrawn. For these tests the emulator and maybe my own Phone > should be enough for now. If it's only android you want to evaluate, you may want to give the i386-android target which should also work with that branch a try. This should work if you do not need OpenGLES or something hardware specific. I do not actually know, but there should be i386/android simulator images available. Performance of those should be much better. :)

I now tried to rebuild for i386. This is the command I used (I already replaced GOLD by the BFD linker):

make all OS_TARGET=android CPU_TARGET=i386
BINUTILSPREFIX=i686-linux-android-
CROSSBINDIR=D:\Android\android-ndk-r8c\toolchains\x86-4.6\prebuilt\windows\bin CROSSOPT="-FlD:\Android\android-ndk-r8c\platforms\android-14\arch-x86\usr\lib"

This is the result:

=== output begin ===

D:/fpc/android/compiler/ppcross386.exe -Tandroid -XPi686-linux-android- -Xr -Ur -Xs -O2 -n -Fui386 -Fusystems -FuD:/fpc/
android/rtl/units/i386-android -Fii386
-FDD:\Android\android-ndk-r8c\toolchains\x86-4.6\prebuilt\windows\bin -FE. -FUi38
6/units/i386-android -dRELEASE
-FlD:\Android\android-ndk-r8c\platforms\android-14\arch-x86\usr\lib -di386 -dGDB -dBROW
SERLOG -Fux86 -Sew pp.pas
i386\units\i386-android\pp.o: file not recognized: File format not recognized
pp.pas(234,1) Error: Error while linking
pp.pas(234,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
make.exe[3]: *** [ppc386] Error 1
make.exe[3]: Leaving directory `D:/fpc/android/compiler' make.exe[2]: *** [cycle] Error 2
make.exe[2]: Leaving directory `D:/fpc/android/compiler' make.exe[1]: *** [compiler_cycle] Error 2
make.exe[1]: Leaving directory `D:/fpc/android'

=== output end ===

Did I miss some specific options?

Regards,
Sven

Reply by email

Sven Barth
to Sven Barth: Then I'll need to recompile for ARMv5... Currently I'm mostly checking what would be…
Sven Barth wrote 26 lines
Am 19.12.2012 16:42, schrieb Thomas Schatzl: > On Wed, 2012-12-19 at 16:20 +0100, Sven Barth wrote: >> Am 18.12.2012 17:47, schrieb Thomas Schatzl: >>> Looking through compiler/systems/t_android.pas, you may want to try >>> commmenting line 343, the one that adds info.Dynamiclinker to the >>> input files. Looks wrong. (system/bin/linker is passed to ld later as >>> --dynamic-linker option later anyway). >> Ok... by removing the addition of the dynamic linker I can successfully >> compile and link the DLL, but when starting it I get an illegal >> instruction error... I have not yet tested whether this can be >> reproduced with an empty library as well. >> >> === logcat begin === >> >> [...] >> >> === logcat end === >> >> Edit: Linking with debug information I could resolve the address to >> InterlockedExchange. Hmm... It seems that the SDK's QEMU does not >> emulate a ARMv6 device? > - yes. See http://developer.android.com/tools/devices/emulator.html. > Btw, there is not much point to compiling for armv6 for Android. The two > official ABIs are either armv5te + softfloat or armv7a + vfpv3_d16 > (maybe v2). Then I'll need to recompile for ARMv5...

I have now managed to compile a simple library (a conversion of the hello-jni example) and execute it. I had made a mistake though which could also be the solution to my LCL problem: I had forgotten to pass -CpARMv5 as the compiler defaults to some other version of ARM. I'll need to recheck this for the LCL example.

Would something speak against making ARMv5 the default CPU type for Android? AFAIK that is the minium that Android supports...

Regards,
Sven

Reply by email

Thomas Schatzl
to Sven Barth: I now tried to rebuild for i386. This is the command I used (I already replaced GOLD by…

Hi,

Sven Barth wrote 24 lines
Am 20.12.2012 10:19, schrieb Thomas Schatzl: > >>> - if you are really interested about doing Android development, I >>> recommend getting a developer board. The emulator is really slow. Even >>> fast developer boards are really cheap now, e.g. quad-core 1.4Ghz ARMv7 >>> with 1GB RAM for 70 USD (www.hardkernel.com , search for Odroid-U). This >>> device is actually pretty decent. Otherwise use an unused phone. >> Currently I'm mostly checking what would be necessary to get our Windows >> Mobile application (more or less) running on Android using >> LCL-CustomDrawn. For these tests the emulator and maybe my own Phone >> should be enough for now. > If it's only android you want to evaluate, you may want to give the > i386-android target which should also work with that branch a try. This > should work if you do not need OpenGLES or something hardware specific. > I do not actually know, but there should be i386/android simulator > images available. Performance of those should be much better. :) I now tried to rebuild for i386. This is the command I used (I already replaced GOLD by the BFD linker): make all OS_TARGET=android CPU_TARGET=i386 BINUTILSPREFIX=i686-linux-android- CROSSBINDIR=D:\Android\android-ndk-r8c\toolchains\x86-4.6\prebuilt\windows\bin CROSSOPT="-FlD:\Android\android-ndk-r8c\platforms\android-14\arch-x86\usr\lib"

make clean crosszipinstall OS_TARGET=android CPU_TARGET=i386 CROSSBINDIR=[...]/android-ndk-r8c/toolchains/x86-4.6/prebuilt/linux-x86/bin BINUTILSPREFIX=i686-linux-android- OPT="" CROSSOPT=" -Cfsse3 -Fl[...]/android-ndk-r8c/platforms/android-14/arch-x86/usr/lib" PP=[...]/targetandroid/ppc386

(compiling from linux-i386 to android-i386)

went through here. Did you make sure that the correct fpcmake is used? (and take care of the bfd/gold issue).

Note that to comply to the ABI, you need -Cfsse3.

You would also need -mstackrealign, but fpc generated code in that branch does not have a 16 byte alignment requirement.

In trunk, iirc, default alignment is 16 bytes too, and there is a new option for forced stack realignment. I think the other fpc developers know better. You may also specify -Cppentium3.

Thomas

Reply by email

Thomas Schatzl
to Sven Barth: I have now managed to compile a simple library (a conversion of the hello-jni example)…

Hi,

On Thu, 2012-12-20 at 17:09 +0100, Sven Barth wrote:

Sven Barth wrote
> Am 19.12.2012 16:42, schrieb Thomas Schatzl: >>>[...] > - yes. See http://developer.android.com/tools/devices/emulator.html. >> Btw, there is not much point to compiling for armv6 for Android.

The two

Show quoted text 8 lines
>> official ABIs are either armv5te + softfloat or armv7a + vfpv3_d16 >> (maybe v2). > Then I'll need to recompile for ARMv5... I have now managed to compile a simple library (a conversion of the hello-jni example) and execute it. I had made a mistake though which could also be the solution to my LCL problem: I had forgotten to pass -CpARMv5 as the compiler defaults to some other version of ARM. I'll need to recheck this for the LCL example.

Default is some unspecified ARM.

Would something speak against making ARMv5 the default CPU type for

Android? AFAIK that is the minium that Android supports...

No. You may report that as a bug/feature request in the tracker already.

I am aware that before merging to trunk a lot of such things to make life easier need to be cleaned up.

Thomas

Reply by email

Sven Barth
to Thomas Schatzl: make clean crosszipinstall OS_TARGET=android CPU_TARGET=i386…
Thomas Schatzl wrote 33 lines
Hi, On Thu, 2012-12-20 at 16:33 +0100, Sven Barth wrote: > Am 20.12.2012 10:19, schrieb Thomas Schatzl: >>>> - if you are really interested about doing Android development, I >>>> recommend getting a developer board. The emulator is really slow. Even >>>> fast developer boards are really cheap now, e.g. quad-core 1.4Ghz ARMv7 >>>> with 1GB RAM for 70 USD (www.hardkernel.com , search for Odroid-U). This >>>> device is actually pretty decent. Otherwise use an unused phone. >>> Currently I'm mostly checking what would be necessary to get our Windows >>> Mobile application (more or less) running on Android using >>> LCL-CustomDrawn. For these tests the emulator and maybe my own Phone >>> should be enough for now. >> If it's only android you want to evaluate, you may want to give the >> i386-android target which should also work with that branch a try. This >> should work if you do not need OpenGLES or something hardware specific. >> I do not actually know, but there should be i386/android simulator >> images available. Performance of those should be much better. :) > I now tried to rebuild for i386. This is the command I used (I already > replaced GOLD by the BFD linker): > > make all OS_TARGET=android CPU_TARGET=i386 > BINUTILSPREFIX=i686-linux-android- > CROSSBINDIR=D:\Android\android-ndk-r8c\toolchains\x86-4.6\prebuilt\windows\bin > CROSSOPT="-FlD:\Android\android-ndk-r8c\platforms\android-14\arch-x86\usr\lib" > make clean crosszipinstall OS_TARGET=android CPU_TARGET=i386 CROSSBINDIR=[...]/android-ndk-r8c/toolchains/x86-4.6/prebuilt/linux-x86/bin BINUTILSPREFIX=i686-linux-android- OPT="" CROSSOPT=" -Cfsse3 -Fl[...]/android-ndk-r8c/platforms/android-14/arch-x86/usr/lib" PP=[...]/targetandroid/ppc386 (compiling from linux-i386 to android-i386) went through here. Did you make sure that the correct fpcmake is used? (and take care of the bfd/gold issue).

The fpcmake problem is taken care of since the last time as I replaced my 2.6.0 fpcmake by the one from the Android branch. Also I replaced the linker with the BFD one from the beginning. Also I tried the 4.4.3 and the 4.6 binutils. The only difference (after adding "-Cfsse3 -Cppentium3") is now that I'm doing this on Windows. I'll retry this at the weekend on Linux. What puzzles me though is the "File format not recognized" when the linker tries to open the "pp.o" file...

Regards,
Sven

Reply by email

Marco van de Voort
to Sven Barth

In our previous episode, Sven Barth said:

Show quoted text 5 lines
Also I replaced the linker with the BFD one from the beginning. Also I tried the 4.4.3 and the 4.6 binutils. The only difference (after adding "-Cfsse3 -Cppentium3") is now that I'm doing this on Windows. I'll retry this at the weekend on Linux. What puzzles me though is the "File format not recognized" when the linker tries to open the "pp.o" file...

What does "file" say about that file?

Reply by email

Sven Barth
to Marco van de Voort
Marco van de Voort wrote 7 lines
In our previous episode, Sven Barth said: > Also I replaced the linker with the BFD one from the beginning. Also I > tried the 4.4.3 and the 4.6 binutils. The only difference (after adding > "-Cfsse3 -Cppentium3") is now that I'm doing this on Windows. I'll retry > this at the weekend on Linux. What puzzles me though is the "File format > not recognized" when the linker tries to open the "pp.o" file... What does "file" say about that file?

It will be hard to have "file" say anything as I'm - as I wrote - currently doing this on Windows. :)

Regards,
Sven

Reply by email

Marco van de Voort
to Sven Barth

In our previous episode, Sven Barth said:

Show quoted text 5 lines
>> this at the weekend on Linux. What puzzles me though is the "File format >> not recognized" when the linker tries to open the "pp.o" file... > What does "file" say about that file? It will be hard to have "file" say anything as I'm - as I wrote - currently doing this on Windows. :)

Cygwin has "file". There are also standalone (VC compiled) versions, but I don't know how recent they are.

Reply by email

Sven Barth
to Marco van de Voort
Marco van de Voort wrote 8 lines
In our previous episode, Sven Barth said: >>> this at the weekend on Linux. What puzzles me though is the "File format >>> not recognized" when the linker tries to open the "pp.o" file... >> What does "file" say about that file? > It will be hard to have "file" say anything as I'm - as I wrote - > currently doing this on Windows. :) Cygwin has "file". There are also standalone (VC compiled) versions, but I don't know how recent they are.

I don't have Cygwin on this computer and I will never have. But I just checked and my other computer where I have Interix installed (or in Windows 7 known as Subsystem for Unix Applications (SUA)) I have "file" and it returns that the pp.o is a COFF file... that explains the problems... -.-

But why? Even if I add "-Aas" or "-Aelf" the internal assembler seems to be used. I don't get it -.-

Regards,
Sven

Reply by email

Marco van de Voort
to Sven Barth

In our previous episode, Sven Barth said:

Show quoted text 6 lines
Windows 7 known as Subsystem for Unix Applications (SUA)) I have "file" and it returns that the pp.o is a COFF file... that explains the problems... -.- But why? Even if I add "-Aas" or "-Aelf" the internal assembler seems to be used. I don't get it -.-

Disable smartlinking maybe? Or AS is used, just not the one you expect?

Reply by email