Charles Boyd on Wed, 27 Jul 2011 09:07:12 +0200

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: cross-compiling pari for Android


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?

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

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?

Alternatively you can use ./Configure -a and fill in the answer to the test,
but that assume you know them.

When I export


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?

Cross-compiling for Android depends on the use of this toolchain, which is only available for x86 -- so compiling directly on a device or in the emulator is not feasible. I tried using GCC 4.6.0 (ARM port) in the Android emulator. This did not work, I suspect because GCC did not cross-compile correctly for Android.

Please find in attachment the pari.cfg file for 2.5.0 on ARM.

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

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?

Android NDK allows you also to write files and a ndk-build script (wrapper around GNU make) which takes out a lot of the work with building native code. This raises the question: Is the most robust way to do this by using the existing PARI/GP build system and modifying it as needed, or writing a parallel build system for Android?

If it is best to do a parallel build for Android, would it be possible to strip-down PARI/GP source tree without breaking anything to just the bare minimum needed for and a dynamically linked GP binary?

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.

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.


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