32 Bit executables in AARCH64 system

[olihey]

Hej,

I am using BittorrentSync on my C1 KODI media center but I would like to exchange that "one" with the C2.
Now, I asked BittorentSync about a AMR64 version and they said

For now it is not supported. Thank you for your suggestion we will consider it for future but sorry no ETA.

The ARM build they provide looks like this:

Code: Select all

root@s95:~# uname -a
Linux s95 3.14.29-18 #1 SMP PREEMPT Thu Feb 4 14:45:38 BRST 2016 aarch64 GNU/Linux
root@s95:~# file btsync
btsync: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=d017c38f574b5c69d0dad750960786bee88ab52b, stripped

So, is there any chance I can get this executable to run on a AARCH64 C2?

(Since I don't have a C2 yet , I do all my tests on a Tronsmart S95 Pro which also features a S905 with the Debian Jessie from XeoSal)

[XeoSal]

Hello my friend,
I am not sure about your specific application possibility but in general we can try installing 32bit applications of armhf branch on the repository just by adding them to dpkg, since the apt-sources doesn't specify any particular architecture:

Code: Select all

odroid:$ sudo dpkg --add-architecture armhf

Then just install your desired armhf application:

Code: Select all

sudo apt-get update
sudo apt-get install *:armhf

(*) = Any Package

In fact, the question is should arm64 be fully backwards-compatible with armel and armhf binaries as it's supposed to be? Currently, I am trying to find out what's the possibility and limits of this on Linux at the moment.

If you want to learn more about Multiarch, refer to this article by Debian:
https://wiki.debian.org/Multiarch/HOWTO

[olihey]

WOW, after adding the "armhf" architecture and installing "libc6:armhf" (incl. adding a small symlink) the btsync executable worked just like that

Amazing, didn't do a full test but I could go through the setup process without any problems.

Thanks!!

[XeoSal]

WOW, after adding the "armhf" architecture and installing "libc6:armhf" (incl. adding a small symlink) the btsync executable worked just like that

Amazing, didn't do a full test but I could go through the setup process without any problems.

Thanks!!

Yeah, one single fact that I am sure about of ARM64 is that it's supposed to be backwards-compatible with armel and armhf however, I am not sure if it's the same in real world, lets find out if it's going to run 32bit applications as reliable as an armhf based system. So, currently I am trying to install chromium-browser of armhf on my distribution then I will post the results.

P.S. Guess what? I just got chromium browser 32bit to work just as reliable as if it was running on an armhf based system LOL. It's very fast, stable and responsive such a great desktop web surfing experience similar to that on ODROID-XU4 even without any accelerations.

My Final Thoughts:
Definitely, ARM64 is fully backwards-compatible with binaries built for armhf or armel no doubts, you can run any 32bit application you want on any Debian/Ubuntu 64bit based system.

[crashoverride]

P.S. Guess what? I just got chromium browser 32bit to work just as reliable as if it was running on an armhf based system LOL.

What is the command you used to install it?

The issue I am having with multi-arch is that apt-get and aptitude do not seem to be smart enough to pull in ALL dependency packages on their own. I have to manually install "*:armhf" for every dependency. This is on the Ubuntu image so I guess my question is: is this the same on Debian?

[Edit]
Just noticed this information is posted elsewhere:

Code: Select all

odroid64:$ sudo dpkg --add-architecture armhf
odroid64:$ sudo apt-get update
odroid64:$ sudo apt-get install chromium-browser-odrobian:armhf libexif12:armhf gtk2-engines-murrine:armhf gtk2-engines-pixbuf:armhf libudev1:armhf

So it appears Debian also has this issue. Does anyone know a way to make apt-get auto-install these dependencies? I need it to be as simple as:

Code: Select all

odroid64:$ sudo apt-get install chromium-browser-odrobian:armhf

I am really hoping I wont have to modify the apt-get source code.

[Edit2]
Note: It is not chrome that I am attempting install. I need to get Mono up and running and it has A LOT of dependencies that I would rather not have to enter manually each time.

[XeoSal]

@crashoverride This is not an issue with the Ubuntu/Debian system, it has something to do with the package maintainer forgetting some core dependencies not listed on its control file, installing a package for a foreign architecture on a platform with a whole different architecture meaning you have to download every single binary of the same architecture required by that application in order for it to work.

I just kept receiving errors in console when I opened chromium-browser without the other dependencies that were not listed, so I found it what's the cause of them and tried to specify the correct binary package needed. The good news is that now I'm very sure we can run any binary compiled for armhf or armel on our arm64 platform.

So, sometimes even famous package maintainers like Ubuntu team will possibly not prepare a perfectly complete dependency list for their packages. Regarding your mono application, I will try getting it to work soon, it may have 1 ~ 3 missing dependencies because I don't think they will forget too many of them.

This is the control file of the chromium browser package on my repository, the dependency list is exactly the same as the package available on the Ubuntu official repository:

Code: Select all

Package: chromium-browser-odrobian
Version: 45.0.2454.101-0ubuntu0.15.04.1.1183
Architecture: armhf
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Installed-Size: 135236
Pre-Depends: dpkg (>= 1.15.6)
Depends: gconf-service, libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.16), libcairo2 (>= 1.6.0), libcups2 (>= 1.4.0), libdbus-1-3 (>= 1.2.14), libexpat1 (>= 2.0.1), libfontconfig1 (>= 2.9.0), libfreetype6 (>= 2.3.9), libgcc1 (>= 1:4.4.0), libgconf-2-4 (>= 3.2.5), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.37.3), libgnome-keyring0 (>= 3.2.2-2~), libgtk2.0-0 (>= 2.24.0), libnspr4 (>= 2:4.9-2~) | libnspr4-0d (>= 1.8.0.10), libnss3 (>= 2:3.14.3), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 (>= 1.14.0), libstdc++6 (>= 4.8), libx11-6 (>= 2:1.4.99.1), libxcomposite1 (>= 1:0.3-1), libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3 (>= 1:5.0), libxi6 (>= 2:1.2.99.4), libxrandr2 (>= 2:1.2.99.2), libxrender1, libxss1, libxtst6, zlib1g (>= 1:1.1.4), bash (>= 4), xdg-utils, chromium-codecs-ffmpeg-extra (= 45.0.2454.101-0ubuntu0.15.04.1.1183) | chromium-codecs-ffmpeg (= 45.0.2454.101-0ubuntu0.15.04.1.1183)
Recommends: chromium-browser-odrobian-l10n
Suggests: webaccounts-chromium-extension, unity-chromium-extension, adobe-flashplugin
Conflicts: chromium-browser-inspector
Replaces: chromium-browser-inspector
Provides: chromium-browser-inspector, www-browser
Filename: pool/main/c/chromium-browser-odrobian/chromium-browser-odrobian_45.0.2454.101-0ubuntu0.15.04.1.1183_armhf.deb
Size: 46814288
MD5sum: 4885bff6b8d38dc4a3f29f53bad54d77
SHA1: 7d86f95ed043f1258d139f58c5050320ccac76b4
SHA256: d0b60b8694c4a5d17041808e96433a3521f4a42192bbab76f541992291cf6e2d
Section: web
Priority: optional
Homepage: http://code.google.com/chromium/
Description: Chromium web browser, open-source version of Chrome
 An open-source browser project that aims to build a safer, faster, and more
 stable way for all Internet users to experience the web.

As you can see we done see any of these listed anywhere:

Code: Select all

libexif12:armhf gtk2-engines-murrine:armhf gtk2-engines-pixbuf:armhf libudev1:armhf

Sometimes dependencies of dependencies will do the job installing other missing packages but that's not the case for every application. The package maintainer could for example expect them to be installed as a result of other packages "must have" dependencies that the system can't work without them already however, it didn't happen on our case as we have 0 armhf packages installed on our arm64 platform.

[crashoverride]

I noted on the Odroibian Jessie 64bit thread that what we probably need is a 32bit OS version running on the 64bit kernel. I suspect this may actually be the optimal configuration. 64bit code can still run. It just becomes the foreign architecture instead of armhf (the roles are reversed).

[edit]
I am currently looking into creating a 32bit test image (debootstrap). I would like to benchmark it against a 64bit OS to see what the performance deltas are.

The main issue it solves is compatibility. Anything doing Just-In-Time compilation (JIT) like browsers (javascript), Mono, and Java will need to have special 64bit support. A recompile alone will not fix it.

[XeoSal]

I noted on the Odroibian Jessie 64bit thread that what we probably need is a 32bit OS version running on the 64bit kernel. I suspect this may actually be the optimal configuration. 64bit code can still run. It just becomes the foreign architecture instead of armhf (the roles are reversed).

[edit]
I am currently looking into creating a 32bit test image (debootstrap). I would like to benchmark it against a 64bit OS to see what the performance deltas are.

The main issue it solves is compatibility. Anything doing Just-In-Time compilation (JIT) like browsers (javascript), Mono, and Java will need to have special 64bit support. A recompile alone will not fix it.

I see, okay then I will release the exact same image again with same features but this time with 32bit rootfs running on Linux 64bit kernel, stay tuned.

[crashoverride]

I suspect this may actually be the optimal configuration.

I should probably quantify that statement.

armv8 (64bit) has twice as many registers that are twice as wide as armv7 (32bit). This means a kernel context switch takes 4X as long to preserve the execution state.

armv8 has 32bit fixed length instructions. armv7 has mixed 16bit/32bit instructions (Thumb2). This means higher code density for armv7 which means more instructions fits into cache and less is pulled from slower memory or loaded from sdcard/zram during a vmm swap operation.

armv8 has more registers which mean less stack usage in certain code. However, armv7 32bit registers means twice as much data fits in the cache.

Its my theory that the highest overall performing system will be one primarily composed of 32bit Thumb2 processes yet utilizing 64bit processes for certain specialized workloads.

[crashoverride]

Apparently armv8 is a better 32bit processor than armv7. This suggests there is a benefit to compiling 32bit code as armv8 AArch32 rather than armv7 A32 (100 new instructions).
http://www.arm.com/products/processors/ ... cessor.php

[meveric]

yepp they had some news about that over here a little while ago.
Also the smaller form factor allows for better energy efficiency.

[berdux]

WOW, after adding the "armhf" architecture and installing "libc6:armhf" (incl. adding a small symlink) the btsync executable worked just like that

Amazing, didn't do a full test but I could go through the setup process without any problems.

Thanks!!

hello!

so, i did run the following commands:
dpkg --add-architecture armhf
apt-get update
apt-get install libc6:armhf

but i still cannot open the btsync executable..
(by running ./btsync)
could you please you explain that small symlink part that you mentioned?

ty very much

[olihey]

If you do

Code: Select all

root@odroid64:~# file btsync 
btsync: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=3afcb0001bdc1d86002cab78b32ddbd2d4c9afca, stripped

you will see that it needs "/lib/ld-linux.so.3" as interpreter to start the executable, which does not exist.

But /lib/ld-linux-armhf.so.3 exists (after you have installed the libc6:armf). So, just do

Code: Select all

root@odroid64:~# ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3
root@odroid64:~# ./btsync 
By using this application, you agree to our Privacy Policy, Terms of Use and End User License Agreement.
https://www.getsync.com/legal/privacy
https://www.getsync.com/legal/terms-of-use
https://www.getsync.com/legal/eula

Webui is listening on 127.0.0.1:8888
BitTorrent Sync forked to background. pid = 717

[uross]

It's even possible to use the official Linux Packages for btsync (https://blog.getsync.com/2016/02/18/off ... available/). The following steps worked for me on a C2 running DietPi.

Follow the instructions above first:

Code: Select all

sudo dpkg --add-architecture armhf
sudo apt-get update
sudo apt-get install libc6:armhf
sudo ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3

Modify the command for adding the repository to contain the "armhf" architecture:

Code: Select all

sudo sh -c 'echo "deb [arch=armhf] http://linux-packages.getsync.com/btsync/deb btsync non-free" > /etc/apt/sources.list.d/btsync.list'

Execute the other steps from https://blog.getsync.com/2016/02/18/off ... available/:

Code: Select all

wget -qO - http://linux-packages.getsync.com/btsync/key.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get install btsync

[lowen]

Apparently armv8 is a better 32bit processor than armv7. This suggests there is a benefit to compiling 32bit code as armv8 AArch32 rather than armv7 A32 (100 new instructions).

This was also the case years ago with 64-bit SPARC. Most 64-bit SPARC Linux distributions (at least back when I did UltraSPARC hardware on Linux in production) did a 64-bit kernel and a 32-bit userland, with 64-bit code if you needed more than 4GB in a single process. So you could have, say, a Sun Enterprise 6500 with 18 CPUs and 24GB of RAM (which we have) running with a 64-bit kernel to manage 24GB of RAM, even though most processes didn't need full access. If the process needed >4GB of RAM, you built it 64-bit. 64-bit code on SPARC is slower than 32-bit code, unlike the x86 versus the AMD 64-bit extensions (x86_64), where 64-bit code can be significantly faster. ARM (like SPARC) is not x86 and the x86 paradigms do not work here.

Split 32/64bit isn't a problem, and can be efficient. And these SBC's do need efficiency. This is emphatically not a "PC."