Bugzilla – Bug 4756
Provide a client package for Linux on ARM (hardfloat)
Last modified: 2014-06-05 09:54:35
You need to
before you can comment on or make changes to this bug.
Some additional investigation is required (see bug 4357), but with some luck,
it will be possible to provide a package with the ThinLinc client that runs on
"most" Linux based ARM systems.
(In reply to comment #0)
> Some additional investigation is required (see bug 4357), but with some luck,
> it will be possible to provide a package with the ThinLinc client that runs on
> "most" Linux based ARM systems.
Actually, it turns out that most existing systems uses softfloat, while the new
& modern standard is to use hardfloat. Thus, I believe we need to provide both
As of r28452, we are shipping a hardfloat ARM client in RPM, DEB, and TGZ
format. Still untested due to lack of hardware.
The client has been tested on Fedora 20 in QEMU. Graphics works fairly well.
Even tested youtube with the funny "Mann gegen Maschine - Ulf Hoffmann
Tischtennis Roboter". Performance is fairly good. We still have a problem with
a long startup time due to Fontconfig cache creation. We need to verify if this
happens on physical devices as well.
We also have a BeagleBone Black now. The shipped distribution is "Angstrom
Distribution (BeagleBone Black - 2GB eMMC) 2013-09-04". There seems to be some
confusion over whether this is actually a hardfloat distro or not. On the
system itself, nothing indicates this: No /lib/ld-linux-armhf.so.3. "readelf -A
/lib/libm.so | grep -i args" returns nothing. However,
indicates that it might be hardfloat anyway, but that the linker is missing.
But it's not very clear. The client currently segfaults.
Wrt Fedora 20, according to
https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation, USB and HDMI
is not yet supported, thus not very practical. A remix is planned but not yet
available. OTOH, it we install using a serial port and then yum upgrade to the
latest packages, it might work.
We have identified a problem with loading libpulsecore-4.0.so on Debian based
distributions. It seems that the dynamic linker is confused about whether the
object is hard or soft float. As I understand it, it can use two different
methods for determining this:
a) check for the new flags:
EF_ARM_ABI_FLOAT_SOFT = 0x200,
EF_ARM_ABI_FLOAT_HARD = 0x400
These were added in binutils 2.24.
b) Check presence of:
Attribute Section: aeabi
Tag_ABI_VFP_args: VFP registers
Also, you might have hardfloat systems which does not try to support softfloat.
In that case, none of this this matter.
We are currently using binutils 2.21. Backporting the new flags is possible.
Unfortunately, it seems this is not enough: On Debian 7 (Beagleboard edition),
adding the new flag improves the situation: "ldd" now works instead of giving
"not a dynamic executable", but it still complains about unable to find
ld-linux-armhf.so.3. Could be related to this bug:
In any case, I guess we need to provide the aeabi attribute section for maximum
compatibility. The problem here is that, depending on the phase of the moon,
these attributes does not survive the rpmbuild process.
(In reply to comment #3)
> We have identified a problem with loading libpulsecore-4.0.so on Debian based
> distributions. It seems that the dynamic linker is confused about whether the
> object is hard or soft float. As I understand it, it can use two different
> methods for determining this:
> a) check for the new flags:
> EF_ARM_ABI_FLOAT_SOFT = 0x200,
> EF_ARM_ABI_FLOAT_HARD = 0x400
> We are currently using binutils 2.21. Backporting the new flags is possible.
Fixed in cenbuild r28645.
(In reply to comment #3)
> In any case, I guess we need to provide the aeabi attribute section for maximum
> compatibility. The problem here is that, depending on the phase of the moon,
> these attributes does not survive the rpmbuild process.
Fixed in cenbuild r28649.
I'd say that this bug is fixed now, and that we are ready for QA testing. I've
testing a few more things on the BeagleBoard Black:
* Sound: works
* Serial port redir: only basic testing, but comm with sercd works
* Local drives: Works with accessing /tmp
* Local printing: Only basic testing, but the job reaches the client.
Wrt smart cards, I've been unable to get any smart card subsystem working in
the current Debian image. Comm seems to hang. However:
* SC tunnel: Works as good from the server as from the client; detects that no
card is present etc.
* SC auth: Hangs, but in the same way as a local pkcs15-tool command.
Tested Fedora 20 on the Wandboard, against Ubuntu 14.04:
- Sound: Builtin doesn't work well, but a USB sound card has no problems.
- Local drives: reading and writing both ok
- Smart card: Both auth and tunneling ok
- Local printing: Works
- Performance: Pretty decent. Similar to a low end x86. Youtube in a standard
size on a Xfce desktop is perfectly smooth. vncviewer is the bottle neck though
as it eats 3-4 times as much CPU as ssh. I also have some problems with cooling
Tested Ubuntu 14.04 on the Wandboard, against the same Ubuntu server. Works as
well as Fedora, although performance is a bit worse. I can see Xorg popping up
in top, so there is something less efficient about the local X server with
Ubuntu. Performance is still quite acceptable though.
(In reply to comment #9)
> Tested Ubuntu 14.04 on the Wandboard...
That's 13.10, not 14.04. Couldn't find any more recent image.
Tested Debian Wheezy on the Wandboard. Sound is broken (bug 5138) and printing
didn't work out of box (bug 5006). Other than that it behaved like Ubuntu.
Tested the primary distributions with ARM hard-float support, so I consider