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 such versions. 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, https://groups.google.com/forum/#!msg/beagleboard/hZ39EQr_tyk/wEahSD1Ui_gJ 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 File Attributes 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: https://sourceware.org/bugzilla/show_bug.cgi?id=15006 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 the wandboard.
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 this done.
