Re: standalone / setuptex on ARM

[Mojca Miklavec <mojca.miklavec.lists@gmail.com>]

Hi,

(I'm adding a few people to CC in case they are interested in the
topic. Feel free to ignore if you aren't :)

On 23 August 2016 at 10:44, Hans Hagen wrote:
> On 8/23/2016 7:46 AM, Philipp Gesang wrote:
>>
>> Hi,
>>
>> when setting up Context for my phone, I noticed the ARM binaries
>> that come with the Standalone don’t work because the system is
>> armv7l soft-float:
>>
>>     $ gcc -v
>>     Using built-in specs.
>>     COLLECT_GCC=gcc
>>     COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
>>     Target: arm-linux-gnueabi
>>     Configured with: ../src/configure -v --with-pkgversion='Debian
>> 4.6.3-14' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
>> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
>> --program-suffix=-4.6 --enable-shared --enable-linker-build-id
>> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
>> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
>> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
>> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
>> --enable-gnu-unique-object --enable-plugin --enable-objc-gc
>> --disable-sjlj-exceptions --with-arch=armv4t --with-float=soft
>> --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi
>> --target=arm-linux-gnueabi
>>     Thread model: posix
>>     gcc version 4.6.3 (Debian 4.6.3-14)
>>
>> Since I’m supplying my own Luatex binary that’s no problem per
>> se, I just had to modify setuptex a bit.
>>
>> Could we add a couple lines like the attached patch to the
>> script? I’m under the impression that “armel” is a Debian
>> specific term so feel free to change it. Though it might be
>> better in general to use the “arm-linux-gnueabi” and
>> “arm-linux-gnueabihf” triplets to separate the platforms.

I don't want to use significantly different names from what TeX Live
uses, so I would prefer to stick with "armel" and "armhf", but the
main point is to be able to differentiate between the two platforms
and so far I wasn't able to without the use of config.guess (which
triggers the compiler etc) or without users manually setting their
platform.

Thanks a lof for the patch.

Just for the reference, here is the code (I put "armhf" to the "else" part):

armv7l)
  # machine id output by uname(1) is
  # insufficent to determine whether this
  # is a soft or hard float system so we
  # check ourselves.
  # a) binutils, this should work almost
  #    everywhere
  if $(which readelf >/dev/null 2>&1); then
    readelf -A /proc/self/exe | grep -q '^ \+Tag_ABI_VFP_args'
    if [ ! $? ]; then
      platform="linux-armel"
    fi
  # b) debian-specific fallback
  elif $(which dpkg >/dev/null 2>&1); then
    if [ "$(dpkg --print-architecture)" = armel ]; then
        platform="linux-armel"
    fi
  # else go with hard fp
  else
    platform="linux-armhf"
  fi
  ;;

The Raspberry PI returns:

$ readelf -A /proc/self/exe
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6"
  Tag_CPU_arch: v6
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6

and both tests fail (like they are supposed to). That's great, I'll
patch the scripts, thank you very much. I was a bit frustrated by the
inability to support both platforms properly.

I'm now waiting for the code for the 64-bit arm binaries :)
I have one in my drawer that I still need to set up.

> i'll let mojca decide that ... (i just ship what she patches in setuptex)

I'll apply the patch. Now, setuptex is not problematic, the same patch
goes there. But mtxrun doing its own guesswork on top of this might
be. Let's see.

And then there's the next question: what hardware/software do we need
if we want to add an additional unit to our (new) build farm? At the
moment Boris is kindly providing the binaries, but it would be nice to
add some small piece of hardware into the cellar that just waits and
starts building automatically whenever there's a need to do so.

Taco, Philipp just volunteered for a presentation (with workshop) at
the ConTeXt Meeting.
Title: Running ConTeXt (and compiling binaries) on my phone.

Mojca

PS: Now looking for the next volunteer to answer a similar problem for
mips (ok, we no longer ship the binaries in ConTeXt, so it's not
really an issue until the next user passes by):
    http://stackoverflow.com/questions/7101038/how-to-distinguish-between-mips-cpu-types-on-linux-when-dpkg-architecture-is-abs
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________