[fpc-devel] Re: Building the Android branch

[Thomas Schatzl]

Hi,

On Tue, 2012-12-18 at 07:30 +0100, Sven Barth wrote:
> 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).

>  > 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.

> 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.

> 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