Front page | perl.perl5.porters |
Postings from January 2014
Re: $^O for Android
Thread Previous
|
Thread Next
From:
Brian Fraser
Date:
January 13, 2014 09:10
Subject:
Re: $^O for Android
Message ID:
CA+nL+nb+cghxaDR4vh1anbRtS0Eb_KWJURj9McYcMNEzEVh82Q@mail.gmail.com
On Sun, Jan 12, 2014 at 8:57 PM, Brian Fraser <fraserbn@gmail.com> wrote:
> On Sun, Jan 12, 2014 at 8:27 PM, Piotr Roszatycki <
> piotr.roszatycki@gmail.com> wrote:
>
>> What should contain $^O for Android port?
>>
>> There are two options already I've noticed: 'linux-androideabi' [1]
>> and 'android' [2]
>>
>
> I will copy paste what I said in the github comment:
>
> [linux-androideabi was] castaway's choice, but it's for the sake of
> Configure & has some background
> in how cross-compilation has previously worked (osname would've been just
> targetarch, sans the first component, e.g. mipsel-linux-android ->
> linux-android, arm-linux-gnueabihf -> linux-gnueabihf, etc. That's getting
> changed in the future). Native android is a hacked Linux system; if we used
> linux-android we don't have to hack Configure to add an extra check for
> android whenever it's looking for Linux; it's also future proofing the
> whole thing, since what's bound to happen is that someone will add a new
> linux branch but not add the |android bit.
>
> Mind you, it might be plausible to add a Configure hook to change osname
> to 'android' after Configure is done but before make is run. I think that's
> probably the way to go, but castaway (who did much of the porting for
> android) should chime in, so please send a mail to perl5-porters about it.
>
I implemented this on
https://github.com/Hugmeir/utf8mess/commit/d15bf0fd4833a3cd5a65675e82febc7104c99da9
That branch now also supports native builds:
$ export SYSROOT=<location of the native toolchain, e.g.
/data/data/com.pdaxrom.cctools/root/cctools>
$ export PATH="$SYSROOT/bin:$PATH"
$ export
LD_LIBRARY_PATH="$SYSROOT/lib:`pwd`:`pwd`/lib:`pwd`/lib/auto:$LD_LIBRARY_PATH"
$ ./Configure -des -Dusedevel -Dsysroot=$SYSROOT -Alibpth="/system/lib
/vendor/lib" -Uusenm -Duseshrplib -Uuserelocatableinc
-Dnoextensions=SDBM_File
Apparently the toolchain provided by CCtools doesn't have nm, ar or ranlib,
so -Uusenm and -Duseshrplib are mandatory. Also, because of the lack of ar,
SDBM_File won't build, so we have to skip it. I'm not sure if the -Alibpth
bit is necessary, but the native gcc doesn't have those by default and I
think it might cause issues detecting libc and libm.
make test fails several thats that are skipped on cross-compile builds, as
well as some related to not having SDBM_File; I haven't investigated any of
those.
On the bright side of things, having a native build to compare against made
me spot two bugs in Configure's handling of cross-compile builds! There's
also one difference that I can't explain yet: in the native build
has fflushNULL='define' but the cross build has it as undef.
Thread Previous
|
Thread Next