We would like to be able to compile tlclient for ARM devices, so we need a build environment for this.
Cross-compiling is one option; another is to set up a qemu environment and compile natively, which may be a simpler alternative. I've managed to compile the client natively on the Raspberry Pi, so it's doable.
We probably need to set up a proper cross-compilation environment for this, rather than use qemu (see bug #4009). Added time estimation.
glibc versions used: - Debian 5.0 (expired, first armel): 2.7 - Debian 6.0 (current stable): 2.11 - Debian 7.0 (unstable, first armhf): 2.13 - Ubuntu 10.04 (LTS, first unofficial armel): 2.11 - Ubuntu 11.10: 2.13 - Ubuntu 12.04 (LTS, first official armel): 2.15 - Ubuntu 12.10: 2.15 - Fedora 13 (first unofficial armv5tel build): 2.12 - Fedora 14: 2.13 - Fedora 15 (first unofficial armv7hl build): 2.14 - Fedora 17 (first official builds): 2.15 - Fedora 18: 2.16
It seems like Ubuntu has stolen Debian's "armel" tag, but uses an incompatible ABI: "The primary difference is the ISA and instruction set targeted in Ubuntu (ARMv7 mostly Thumb2), rendering nearly all packages incompatible at a binary level." https://wiki.ubuntu.com/ARM Idiots...
And looking at this page, it seems like they even keep screwing themselves over by having different definitions for "armel" depending on Ubuntu version: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto A for effort!
Fedora has apparently dropped the ARMv5 arch and will only build for ARMv7. Have to check what the other distributions (and toaster vendors) are doing, but we might only have to support a single ARM arch.
It seems the situation has improved now and that Fedora, Debian, and Ubuntu are now targeting the same architecture: ARMv7 CPU with Thumb-2 and VFP3D16 LSB has not yet done anything wrt ARM: https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=909 The above requirements does not guarantee that NEON is available. NEON is included in all Cortex-A8 devices but is optional in Cortex-A9 devices. As seen on https://wiki.debian.org/ArmHardFloatPort#Partial_reference_of_SoC_and_supported_ISAs, Nvidia Tegra2 and Marvell Dove does not have it. We could consider adding NEON as an additional requirement. XBMC does that (http://wiki.xbmc.org/?title=Supported_hardware). Tegra3 supports NEON, probably Tegra4 as well.
I've checked out the Citrix Receiver for Linux ARM. They have two versions: ARMEL and ARMHF. I've failed to find any information about which ARM CPUs are actually supported. Wrt glibc version, the general Linux documentation says "glibc 2.11.3 or later". However, when checking the actual binaries, I find: 0x06969195 0x00 10 GLIBC_2.15 0x0d696917 0x00 09 GLIBC_2.7 0x06969191 0x00 06 GLIBC_2.11 0x0d696914 0x00 02 GLIBC_2.4 In other words, the requirement seems to be 2.15 in practice.
If we disregard "armel", a summary wrt the glibc situation would be: - Debian 7.0 (unstable, first armhf): 2.13 - Ubuntu 11.10: 2.13 - Ubuntu 12.10: 2.15 - Fedora 17 (first official builds): 2.15 - Fedora 18: 2.16 - Citrix Receiver req: 2.11.3 / 2.15 - HP t410: 2.11.1 - IGEL IZ1: FIXME - Wyse T50: 2.11.1 - eLux RT: 2.12.2 latest glibc 2.11.X is 2.11.3 - seems like good choice.
(In reply to comment #9) > latest glibc 2.11.X is 2.11.3 - seems like good choice. Note however that it doesn't support ARM directly; one must use glibc-ports. I'm going to assume that one needs to match the version, thus glibc-ports 2.11 will be tried.
> - IGEL IZ1: FIXME The IGEL firmware file lxarm.sys contains references to libc-2.13.so, so we can probably assume that the IZ1 uses 2.13.
It turned out that although the "new" standard in modern distributions is to use hardfloat, most current systems are actually using the old softfloat ABI. This includes the four terminals HP t410, Wyse T50, eLux RT, IGEL IZ1. So, if we are going to support these, we need to provide a softfloat build environment as well. Also, there's an issue with which ld-linux to use, as pointed out by: https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 I've checked out a few systems: - glibc 2.11.3 default: /lib/ld-linux.so.3 - Fedora 17 (first official builds): /lib/ld-linux.so.3 - Citrix Receiver ARMEL: /lib/ld-linux.so.3 - HP t410: /lib/ld-linux.so.3 - Wyse T50: Based on Ubuntu 10.04: /lib/ld-linux.so.3 - eLux RT: /lib/ld-linux.so.3 - IGEL IZ1: /FIXME - Ubuntu 11.10: /lib/arm-linux-gnueabihf/ld-linux.so.3 - Debian <7: /lib/arm-linux-gnueabihf/ld-linux.so.3 - Ubuntu 12.10: /lib/ld-linuxarmhf.so.3 - Debian 7.0 (unstable, first armhf): /lib/ld-linux-armhf.so.3 - Fedora 18 and later: /lib/ld-linux-armhf.so.3 - Citrix Receiver ARMHF: /lib/ld-linux-armhf.so.3 - New common standard: /lib/ld-linux-armhf.so.3 I believe we should be able to use /lib/ld-linux.so.3 for any softfloat ("armel") binaries and /lib/ld-linux-armhf.so.3 for hardfloat binaries. We won't cover old Debian and Ubuntu systems, but I think we can live with that.
Tested on Fedora 20 on QEMU now, works. The startup is somewhat slow, ~2 minutes. The problem seems to be the fonts handling. Using strace, I can see that it works on every font in /usr/share/fonts/ for several minutes. When using strace, the startup takes multiple hours: I've been running for 2 hours so far. I also get: Fontconfig error: Cannot load default config file
Our hack to gcc to avoid libgcc_s dependencies has been sent upstream: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428
I believe this bug is solved now. We have a working build environment, and the Linux ARM client (see bug 4756) has been tested in Qemu and also a cubieboard with a customized Debian distro.
The client has been fully tested without issue, so the build environment is assumed to be sane.
