|Bill Allombert on Wed, 27 Jul 2011 17:11:54 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: cross-compiling pari for Android|
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.