Bug 4357 - Set up a cross-compiler for "hard-float" ARM
Summary: Set up a cross-compiler for "hard-float" ARM
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Build system (show other bugs)
Version: 3.4.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.2.0
Assignee: Peter Åstrand
Keywords: ossman_tester, prosaic
Depends on:
Blocks: 4009 4756 5000
  Show dependency treegraph
Reported: 2012-06-28 13:15 CEST by Aaron Sowry
Modified: 2014-05-12 15:55 CEST (History)
0 users

See Also:
Acceptance Criteria:


Description Aaron Sowry cendio 2012-06-28 13:15:51 CEST
We would like to be able to compile tlclient for ARM devices, so we need a build environment for this.
Comment 1 Aaron Sowry cendio 2012-07-09 13:13:46 CEST
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.
Comment 2 Aaron Sowry cendio 2012-09-18 14:03:30 CEST
We probably need to set up a proper cross-compilation environment for this, rather than use qemu (see bug #4009). Added time estimation.
Comment 3 Pierre Ossman cendio 2012-10-26 10:30:42 CEST
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
Comment 4 Pierre Ossman cendio 2012-10-26 10:32:47 CEST
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."


Comment 5 Pierre Ossman cendio 2012-10-26 10:36:27 CEST
And looking at this page, it seems like they even keep screwing themselves over by having different definitions for "armel" depending on Ubuntu version:


A for effort!
Comment 6 Pierre Ossman cendio 2013-11-15 11:26:00 CET
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.
Comment 7 Peter Åstrand cendio 2014-01-13 14:18:27 CET
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:


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.
Comment 8 Peter Åstrand cendio 2014-01-15 10:58:35 CET
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.
Comment 9 Peter Åstrand cendio 2014-01-15 14:35:48 CET
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


 - Wyse T50: 2.11.1

 - eLux RT: 2.12.2

latest glibc 2.11.X is 2.11.3 - seems like good choice.
Comment 10 Peter Åstrand cendio 2014-01-15 15:47:21 CET
(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.
Comment 11 Peter Åstrand cendio 2014-01-20 09:00:36 CET

The IGEL firmware file lxarm.sys contains references to libc-2.13.so, so we can probably assume that the IZ1 uses 2.13.
Comment 12 Peter Åstrand cendio 2014-02-19 14:46:09 CET
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:


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.
Comment 13 Peter Åstrand cendio 2014-03-04 12:36:12 CET
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
Comment 14 Pierre Ossman cendio 2014-03-05 12:52:25 CET
Our hack to gcc to avoid libgcc_s dependencies has been sent upstream:

Comment 15 Peter Åstrand cendio 2014-03-10 09:53:38 CET
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.
Comment 16 Pierre Ossman cendio 2014-05-12 15:55:51 CEST
The client has been fully tested without issue, so the build environment is assumed to be sane.

Note You need to log in before you can comment on or make changes to this bug.