develooper Front page | perl.perl5.porters | Postings from December 2012

JROBINSON grant report #11.5, #14

Jess Robinson
December 29, 2012 13:05
JROBINSON grant report #11.5, #14
Message ID:
Grant report #11.5

The things I did while ill/abroad and failed to report on:

October 12th:
Adapted to set $^O according to targetarch/osname from  
%Config (this was an idea from Nicholas ages ago), this way modules that  
use hints such as Time::HiRes will load the correct hints file for the  
target arch when being built.

October 19th:
Decided to work on an actual useful patch against current blead based on  
my excavations so far. Ported the --sysroot (-Dsysroot) usage to a new  
branch against current blead, together with the locating of headers &  
libraries based on that path. This is used whenever it is supplied,  
cross-compiling or not.

November 30th:
Added the sysroot Errno patch to the new branch, prepared patches of the  
changes and sent them to p5p mailing list.. Still hoping someone will  
smoke those!


Oct 12th - 4:30h
Oct 19th - 6:45h
Nov 30th - 2:00h

Total: 13:15h

Grant report #14

After working with RunPerl and actual android testing last week, I  
discovered that one can actually copy binaries to the Android emulator,  
and run them remotely (previously I thought this wasn't possible). I  
decided therefore to look at the existing/most recent cross-compilation  
work in Configure again. This currently attempts to copy every small test  
program to a remote test host via ssh, run it, and report back the results.

On Android using adb, this turns out to be possible, if somewhat painful.  
Ssh returns the exit code of the remote program it is running, adb shell  
does not (there are many complaints and a bug report against android about  
this online, but no sign of movement since it was reported in 2009). With  
help/ideas from James I eventually produced this:

     doexit="echo \$?"
     case "$1" in
     case "$cwd" in
     '') cwd=/data/data/test ;;
     # send copy results to /dev/null as otherwise it outputs speed stats  
which gets in our way.
$exe > /dev/null 2>&1

     foo=`adb -s emulator-5554 shell "sh -c '(cd $cwd && $exe $@ >  
$exe.stdout) ; $doexit '"`
     # We get back Ok\r\n on android for some reason, grrr:
     result=`cat $exe.stdout`
     rm $exe.stdout
     foo=`echo $foo | sed -e 's|\r||g'`
     # Also, adb doesn't exit with the commands exit code, like ssh does,  
     echo $result
     exit $foo

For a while I had added an extra "-exit" argument to conditionally return  
either the exit code or STDOUT value, but this requires use of "$run  
-exit" in Configure to mean something when $run contains no script at all,  
which is the default for non-cross-compile. "-cwd" is copied from the  
run-ssh scripts, however I see no use of this anywhere, and it has the  
same issue just mentioned, so I shall probably remove it from both.

In the process I also dropped the "if $exe.xok already exists locally,  
don't copy the file to the remote system, we already did" approach in the  
existing run-ssh script. As many of the Configure tests use the same name  
"try", this doesn't work, and I'm not sure of the reasoning behind it.

The run-adb-shell (and to-adb-push, from-adb-pull) scripts are created in  
the android hints file, which is now named "" as this  
is what the existing Configure section guesses as the targetarch value  
 from the gcc name "arm-linux-androideabi-gcc". This seems fairly sane to  
me as any checks for "linux-like" in Configure can be made to be "linux*"  
and continue to work.

If we now setup the command line to supply the emulator name and a  
directory on that host that we can copy to and run from, it now looks like  

./Configure -des -Dusedevel -Dusecrosscompile -Dtargethost="emulator-5554"  
-Dcc=arm-linux-androideabi-gcc 2>&1 | tee -a android-compile.log

You'll need to create & start an android emulator first, of course.

During this I also extracted the code that depends on "targethost", which  
is used to determine whether we are setting up "run" scripts at all or  
not, out from under "usecrosscompile" section, as those seem to be  
separately useful things. This also allows us to move it to after the  
hints file is loaded, or even into the hints files themselves.

At this point I had Configure running through again, and running most of  
the tests (some don't complile but all get answers enough to finish). I  
then tried to "make perl", to discover that the setting of "run" not only  
ends up in %Config, but is also used in, Makefile.SH and  
MM_Unix to try and run all miniperl calls and similar on the remote  
target. I started to remove these, as it feels like "cross compiling"  
should not involve "building things on the target", as that's what we're  
trying to avoid doing in general. I emailed P5P to see if anyone  
disagrees.. so far no takers.

I also spent some time looking at Neil's Makefile.SH patch, which is  
essentially a way to configure an external (mini)perl to use when  
cross-compiling, to run and other perl-requiring parts. I  
intend to integrate it with my current aim of building a host miniperl in  
a host/ subdirectory using mksymlinks. This will then live in  
Config{hostperl} or similar, which Neil can overwrite if needed for Debian  

Thus this current builds a Perl binary, but not yet any of the Core  
modules. I'll get that sorted next.


1:15h  - Admin (report writing etc)
0:45h  - Looking at Makefile.SH patch from Neil and emailing
2:00h  - Repair issues with Android emulator locally (gpu emulation  
15:30h - Implement new hints file using adb for  
run/to/from scripts.

Total: 19:30h Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About