32 Bit executables in AARCH64 system

Post Reply
olihey
Posts: 34
Joined: Mon Sep 23, 2013 5:20 pm
languages_spoken: english
ODROIDs: C2
Location: Germany
Has thanked: 0
Been thanked: 0
Contact:

32 Bit executables in AARCH64 system

Post by olihey »

Hej,

I am using BittorrentSync on my C1 KODI media center but I would like to exchange that "one" :D 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
Posts: 925
Joined: Sun Aug 30, 2015 11:21 pm
languages_spoken: English
ODROIDs: C1, C1+, C2 & XU4
Has thanked: 0
Been thanked: 0
Contact:

Re: 32 Bit executables in AARCH64 system

Post by 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
Posts: 34
Joined: Mon Sep 23, 2013 5:20 pm
languages_spoken: english
ODROIDs: C2
Location: Germany
Has thanked: 0
Been thanked: 0
Contact:

Re: 32 Bit executables in AARCH64 system

Post by olihey »

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

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

Thanks!!

XeoSal
Posts: 925
Joined: Sun Aug 30, 2015 11:21 pm
languages_spoken: English
ODROIDs: C1, C1+, C2 & XU4
Has thanked: 0
Been thanked: 0
Contact:

Re: 32 Bit executables in AARCH64 system

Post by XeoSal »

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

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. :D

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. ;)
Attachments
ODROBIAN-Chromium-C2.png

crashoverride
Posts: 5184
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 389 times
Contact:

Re: 32 Bit executables in AARCH64 system

Post by crashoverride »

XeoSal wrote: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
Posts: 925
Joined: Sun Aug 30, 2015 11:21 pm
languages_spoken: English
ODROIDs: C1, C1+, C2 & XU4
Has thanked: 0
Been thanked: 0
Contact:

Re: 32 Bit executables in AARCH64 system

Post by 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
Posts: 5184
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 389 times
Contact:

Re: 32 Bit executables in AARCH64 system

Post by 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
Posts: 925
Joined: Sun Aug 30, 2015 11:21 pm
languages_spoken: English
ODROIDs: C1, C1+, C2 & XU4
Has thanked: 0
Been thanked: 0
Contact:

Re: 32 Bit executables in AARCH64 system

Post by XeoSal »

crashoverride wrote: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
Posts: 5184
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 389 times
Contact:

Re: 32 Bit executables in AARCH64 system

Post by crashoverride »

crashoverride wrote: 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
Posts: 5184
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1
Has thanked: 0
Been thanked: 389 times
Contact:

Re: 32 Bit executables in AARCH64 system

Post by 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

User avatar
meveric
Posts: 11254
Joined: Mon Feb 25, 2013 2:41 pm
languages_spoken: german, english
ODROIDs: X2, U2, U3, XU-Lite, XU3, XU3-Lite, C1, XU4, C2, C1+, XU4Q, HC1, N1, Go, H2 (N4100), N2, H2 (J4105), GoA, C4, HC4
Has thanked: 52 times
Been thanked: 423 times
Contact:

Re: 32 Bit executables in AARCH64 system

Post by meveric »

yepp they had some news about that over here a little while ago.
Also the smaller form factor allows for better energy efficiency.
Donate to support my work on the ODROID GameStation Turbo Image for U2/U3 XU3/XU4 X2 X C1 as well as many other releases.
Check out the Games and Emulators section to find some of my work or check the files in my repository to find the software i build for ODROIDs.
If you want to add my repository to your image read my HOWTO integrate my repo into your image.

berdux
Posts: 20
Joined: Thu Mar 24, 2016 1:20 am
languages_spoken: english
ODROIDs: C2
Has thanked: 0
Been thanked: 0
Contact:

Re: 32 Bit executables in AARCH64 system

Post by berdux »

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

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
Posts: 34
Joined: Mon Sep 23, 2013 5:20 pm
languages_spoken: english
ODROIDs: C2
Location: Germany
Has thanked: 0
Been thanked: 0
Contact:

Re: 32 Bit executables in AARCH64 system

Post by 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
Posts: 16
Joined: Sat May 07, 2016 8:40 pm
languages_spoken: english german
ODROIDs: C2, HC1
Has thanked: 0
Been thanked: 0
Contact:

Re: 32 Bit executables in AARCH64 system

Post by 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
Posts: 19
Joined: Sun Mar 27, 2016 5:23 am
languages_spoken: english
ODROIDs: ODROID-C2
Has thanked: 0
Been thanked: 0
Contact:

Re: 32 Bit executables in AARCH64 system

Post by lowen »

crashoverride wrote: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."

Post Reply

Return to “General Topics”

Who is online

Users browsing this forum: No registered users and 0 guests