Re: cross-compiling pari for Android

[Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>]

On Wed, Jul 27, 2011 at 03:06:45AM -0400, Charles Boyd wrote:
> Hi,
> 
> Thanks for your helpful replies. I have some more questions.
> 
>  Instead, I am suggesting to run the tests in an emulator
> > using the environment variable RUNTEST, but still using the cross-compiler
> > for everything else.
> >
> 
> If the way I usually invoke the Android emulator (open root shell only, no
> graphics) is by using the command
> 
> $ emulator -avd android3 -shell -no-window
> 
> then is this what I should have RUNTEST pointing to?

Looking at the documentation of emulator, I do not think it would work.

> I understand in principle what this variable is for, I'm just not clear on
> its usage and haven't seen examples.

See
http://pari.math.u-bordeaux.fr/archives/pari-dev-0912/msg00013.html
for an example.

> The idea, just to be clear, is that I do all of the cross-compiling on my
> Linux host using the toolchain as usual, but pipe the tests through to the
> emulator somehow?

Yes. RUNTEST must point to a program that take a command-line in argument, run
it in the emulator and return the output.

If you can connect to the emulator through ssh emu, then you can write a script

#!/bin/sh 
scp $1 emu:
ssh foo $*

Or you can use sshfs to share your tree between the emulator and the host.
and set RUNTEST to "ssh foo". It is probably safer.

> When I export
> 
> CC=$(ANDROID_TOOLCHAIN)/bin/arm-linux-androideabi-gcc
> 
> and run ./Configure -a, I get an error message complaining that I do not
> have an ANSI compliant C compiler.
> 
> It does not matter here what I do with RUNTEST. I have tried setting it to
> automatically pass (/bin/true) everything, but it seems the ANSI check
> happens (and fails) regardless. How can I trick (or better yet, avoid) this
> check?

You do something wrong. Either RUNTEST is not exported or the compilation
fails, or you are not using PARI/GP 2.5.0.
I tried RUNTEST=/bin/true CC=/bin/true ./Configure and it did succeed even
though no binary is produced by CC.

> Could I adjust this just so CC (and LD, CFLAGS, etc...) are specific for
> Android and get the shared library to compile?

In principle yes. However the C library is not the same, so it might not support the 
same features.

> What would be the procedure for getting this to work robustly such that it
> could be pushed upstream? Aside from the Configure script, what else might I
> have to modify?

I do not expect you should have anything to change in Configure. Configure probably already
support your platform. Just publish your pari.cfg file and/or your RUNTEST script.
If the android libc is not supported by PARI (unlikely) then you will have to add support
for it in src/gp and src/language.

> In other words -- if I wanted to avoid using the Configure script entirely
> (for now, I could modify it later to generate/use Android-specific build
> process once all the issues are worked out first by hand), what should I
> keep in mind? It looks like the Configure script is doing a lot.

Once you have a working pari.cfg, just do
./Configure -l pari.cfg.

(The pari.cfg file is created inside the object directory O*-*/

> Thanks again for your help. Sorry for so many questions, but PARI has a
> somewhat complex build environment and this cross-compiling toolchain does
> not make things easier. I want to get PARI/GP ported to Android as quickly
> as possible so I can start building an application around the library that
> can be used on tablets. 

May I ask what will you application do ? Will you release it under the GNU GPL ?

> (Forgot to reply-all earlier, sorry. Back on the list now).

Thanks for that.

Cheers,
Bill.