standalone / setuptex on ARM
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. Best, Philipp
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'll let mojca decide that ... (i just ship what she patches in setuptex) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
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-c...
On 23 August 2016 at 11:15, Mojca Miklavec wrote:
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:
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'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.
Can you please try to fetch first-setup.sh again and try to reinstall ConTeXt? You should get LuaTeX beta-0.90.0 r5889 which is a bit old, but just to check whether things work at all. If Luigi plans to make a new release today, it makes no sense to rebuild the binary now (building might take longer than waiting for a new release :) Mojca
On 23 August 2016 at 12:03, Mojca Miklavec wrote:
On 23 August 2016 at 11:15, Mojca Miklavec wrote:
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.
Can you please try to fetch first-setup.sh again and try to reinstall ConTeXt? You should get LuaTeX beta-0.90.0 r5889 which is a bit old, but just to check whether things work at all. If Luigi plans to make a new release today, it makes no sense to rebuild the binary now (building might take longer than waiting for a new release :)
OK, so Hans' RPi returns (among others): $ readelf -A /proc/self/exe Tag_CPU_name: "6" Tag_CPU_arch: v6 Tag_THUMB_ISA_use: Thumb-1 Tag_FP_arch: VFPv2 Tag_ABI_HardFP_use: SP and DP Tag_ABI_VFP_args: VFP registers and the Android by Lutz returns: $ readelf -A /proc/self/exe Tag_CPU_name: "7-A" Tag_CPU_arch: v7 Tag_THUMB_ISA_use: Thumb-2 Tag_FP_arch: VFPv3-D16 Tag_ABI_HardFP_use: SP and DP Tag_ABI_VFP_args: VFP registers So his platform gets recognised as armhf and uses the binaries compiled on RPi, but it gives strange results. Lutz, I suggest you come to the ConTeXt Meeting (train ticket to Zwolle costs just 29-39 EUR) and don't let Luigi & Philipp away from their keybords until your problem gets fixed :) :) :) Mojca
On Tue, Aug 23, 2016 at 12:53 PM, Mojca Miklavec
On 23 August 2016 at 12:03, Mojca Miklavec wrote:
On 23 August 2016 at 11:15, Mojca Miklavec wrote:
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.
Can you please try to fetch first-setup.sh again and try to reinstall ConTeXt? You should get LuaTeX beta-0.90.0 r5889 which is a bit old, but just to check whether things work at all. If Luigi plans to make a new release today, it makes no sense to rebuild the binary now (building might take longer than waiting for a new release :)
OK, so Hans' RPi returns (among others):
$ readelf -A /proc/self/exe Tag_CPU_name: "6" Tag_CPU_arch: v6 Tag_THUMB_ISA_use: Thumb-1 Tag_FP_arch: VFPv2 Tag_ABI_HardFP_use: SP and DP Tag_ABI_VFP_args: VFP registers
and the Android by Lutz returns:
$ readelf -A /proc/self/exe Tag_CPU_name: "7-A" Tag_CPU_arch: v7 Tag_THUMB_ISA_use: Thumb-2 Tag_FP_arch: VFPv3-D16 Tag_ABI_HardFP_use: SP and DP Tag_ABI_VFP_args: VFP registers
So his platform gets recognised as armhf and uses the binaries compiled on RPi, but it gives strange results.
Lutz, I suggest you come to the ConTeXt Meeting (train ticket to Zwolle costs just 29-39 EUR) and don't let Luigi & Philipp away from their keybords until your problem gets fixed :) :) :)
I wonder if we have to consider Android instead of ARM. -- luigi
···
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).
Yep, I tested on one of my Π’s. ;)
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 :)
Can’t help with that directly, I have a Π3 but it’s still running a 32 bit distro.
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.
I’ve set up a scratchbox [0] cross build env that produces usable binaries. Maybe if I manage to get that automated I could provide the soft-float binary. (I’ve only built Luatex so far, not sure what else is needed.)
Taco, Philipp just volunteered for a presentation (with workshop) at the ConTeXt Meeting. Title: Running ConTeXt (and compiling binaries) on my phone.
The hard part is displaying the PDFs. I’ll be glad to answer questions but I doubt many would be interested on the oddities of exotic 7 years old hardware =) Thanks for including the patch, Philipp [0] This one: http://www.scratchbox.org/ -- not \box \scratchbox!
participants (4)
-
Hans Hagen -
luigi scarso -
Mojca Miklavec -
Philipp Gesang