Bug 4357 - Set up a cross-compiler for "hard-float" ARM
: Set up a cross-compiler for "hard-float" ARM
: ThinLinc
Build system
: 3.4.0
: PC Unknown
: P2 Normal
: 4.2.0
Assigned To:
: 4009 4756 5000
  Show dependency treegraph
Reported: 2012-06-28 13:15 by
Modified: 2014-05-12 15:55 (History)
Acceptance Criteria:



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

Description From cendio 2012-06-28 13:15:51
We would like to be able to compile tlclient for ARM devices, so we need a
build environment for this.
------- Comment #1 From cendio 2012-07-09 13:13:46 -------
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 From cendio 2012-09-18 14:03:30 -------
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 From cendio 2012-10-26 10:30:42 -------
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 From cendio 2012-10-26 10:32:47 -------
It seems like Ubuntu has stolen Debian's "armel" tag, but uses an incompatible

"The primary difference is the ISA and instruction set targeted in Ubuntu
(ARMv7 mostly Thumb2), rendering nearly all packages incompatible at a binary


------- Comment #5 From cendio 2012-10-26 10:36:27 -------
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 From cendio 2013-11-15 11:26:00 -------
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 From cendio 2014-01-13 14:18:27 -------
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
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 From cendio 2014-01-15 10:58:35 -------
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 From cendio 2014-01-15 14:35:48 -------
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 From cendio 2014-01-15 15:47:21 -------
(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 From cendio 2014-01-20 09:00:36 -------

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 From cendio 2014-02-19 14:46:09 -------
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 From cendio 2014-03-04 12:36:12 -------
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 From cendio 2014-03-05 12:52:25 -------
Our hack to gcc to avoid libgcc_s dependencies has been sent upstream:

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