Multiarch support Rock64

[Farley56]

Couple questions on multiarch support. Been trying to get JRiver MediaCenter23 to run on the Rock64. They don't have an arm64 version so suggested adding armhf architecture. I think I got the architecture added correctly, supposedly no libraries missing. Problem is that I get a "segmentation fault" error when starting the app. I've checked old posts on their forum. In 2016 there were posts from a user wanting to get multiarch support added so they could load the app on a Pine64.
1. Is it possible to run a 32bit armhf app on Ayufan's Stretch minimal build?
2. Anyone have some ideas on what to look for regarding the segmentation fault? Evidently the pertinent line in the kern log I posted on the JRiver forum is;
mediacenter23 (1585) unhandled level 3 translation fault (11) at 0x00000000

Any info would be appreciated. Thanks

[stuartiannaylor]

Couple questions on multiarch support. Been trying to get JRiver MediaCenter23 to run on the Rock64. They don't have an arm64 version so suggested adding armhf architecture. I think I got the architecture added correctly, supposedly no libraries missing. Problem is that I get a "segmentation fault" error when starting the app. I've checked old posts on their forum. In 2016 there were posts from a user wanting to get multiarch support added so they could load the app on a Pine64.
1. Is it possible to run a 32bit armhf app on Ayufan's Stretch minimal build?
2. Anyone have some ideas on what to look for regarding the segmentation fault? Evidently the pertinent line in the kern log I posted on the JRiver forum is;
mediacenter23 (1585) unhandled level 3 translation fault (11) at 0x00000000

Any info would be appreciated. Thanks

Prob not its Arm64 and not ArmHF so as soon as you get a ArmHF instruction bye.
You need to compile from source to Arm64 or they do.

[Farley56]

Clarification;
Is it possible to run 32 bit armhf app if multiarch support (armhf architecture) has been added to the arm64 build? Supposedly Debian Stretch is capable of multiarch support. How one gets it added correctly and whether the Ayufan rock64 arm64 build will allow it is for discussion. Thanks

[stuartiannaylor]

Clarification;
Is it possible to run 32 bit armhf app if multiarch support (armhf architecture) has been added to the arm64 build? Supposedly Debian Stretch is capable of multiarch support. How one gets it added correctly and whether the Ayufan rock64 arm64 build will allow it is for discussion. Thanks

As far as I know multiarch is for cross compiling and still will not let you run a binary on the wrong architecture.
Its not an emulator.
With the current image you need a Arm64 version, that is prob the simple answer.
Unless your going to run through qemu or something.

[ayufan]

Yes. Armhf is supported by rock64 and my builds. OMV uses multi-arch: the system is in armhf, but some bits are arm64z

[Farley56]

Got it, appreciate the info. A dead issue because they probably won't be making an arm64 version as they already have amd64, armhf and i386 versions. I might be the only one who wants to try and get it running on arm64, no upside for them. I have it running on the Xenial Mate build but it's not real robust and I wanted to utilize the debian stretch build as it's more recent and 64bit. I can get access to the server anyway via web browser but getting it to run on the stretch build was a challenge so why not try. Just can't seem to give it up as a fail but I can't make it happen as it's not in my control, so time to put it to bed.

[stuartiannaylor]

Got it, appreciate the info. A dead issue because they probably won't be making an arm64 version as they already have amd64, armhf and i386 versions. I might be the only one who wants to try and get it running on arm64, no upside for them. I have it running on the Xenial Mate build but it's not real robust and I wanted to utilize the debian stretch build as it's more recent and 64bit. I can get access to the server anyway via web browser but getting it to run on the stretch build was a challenge so why not try. Just can't seem to give it up as a fail but I can't make it happen as it's not in my control, so time to put it to bed.

They prob will do as Arm64 is relatively new but looking like becoming the defacto Arm architecture.
Its sort of like only doing I386 for Intel and not a great long term view.

Android and the phone market leads the majority of Arm architecture and think it was only Kitkat (2014) that introduced 64bit but since then 32bit and ArmHf is becoming less and less frequent.
I doubt very much they won't be making for Arm64 and its more likely they are just hiding that they haven't yet just recompiled on Arm64.

Maybe I am wrong and its just a matter of sudo

Code:

dpkg --add-architecture armhf

but got the feeling things don't work that easy on Arm, but could just be kernel support.
Ain't got my Rock yet so can not test, maybe someone will.

[ayufan]

It works. The newer server ARM64 chips do not support ARM32. All customer chips do support ARM32/64 today as this is kind of requirement to run Android apps where not every application is compiled for arm64.

---

Most of my builds run ARM64, just some using ARMHF (OMV) where it is more appropriate given today's compatibility.

[Farley56]

Maybe there's hope! Good to know, thanks. I did add the armhf architecture and checked that it showed up as a foreign-architecture. Added the armhf repos, also dpkg'd the armhf libraries I got from debian.org. JRiver folks did confirm that I wasn't missing any libraries which was good. Couldn't get past the segmentation fault so the app would never fire up. Could it be a permission problem? If so, I'd assume I'd get a different error. I defer to others as I'm in over my head. The great thing is that when I bork the image I just re-Etcher it and start anew. I've loosely documented what I've tried and eliminate/add different things but get the same result. My head hurts from banging it against the wall...might be approaching the whole insanity thing.   The worst thing is that I still believe at some point I had the armhf version running on the stretch build but I can't reproduce it. Tinker, sailor, soldier, spy. I'll keep playing till I die!

[stuartiannaylor]

Maybe there's hope! Good to know, thanks. I did add the armhf architecture and checked that it showed up as a foreign-architecture. Added the armhf repos, also dpkg'd the armhf libraries I got from debian.org. JRiver folks did confirm that I wasn't missing any libraries which was good. Couldn't get past the segmentation fault so the app would never fire up. Could it be a permission problem? If so, I'd assume I'd get a different error. I defer to others as I'm in over my head. The great thing is that when I bork the image I just re-Etcher it and start anew. I've loosely documented what I've tried and eliminate/add different things but get the same result. My head hurts from banging it against the wall...might be approaching the whole insanity thing.   The worst thing is that I still believe at some point I had the armhf version running on the stretch build but I can't reproduce it. Tinker, sailor, soldier, spy. I'll keep playing till I die!

Dunno as being wrong is great news for me as since the Arm Suse (SLES 64 bit) I had it in my head that Arm was not a simple matter for 32 & 64 bit and been planning on hitting compiling needs for some of the stuff I want to do with the Rock.

The segfault is memory addressing I think and it sort of does sound like maybe a call or lib is maybe 32/64 whilst maybe should be 64/32.
Eagerly did a bit of reading after this.

Have you done an apt-get update and apt-get upgrade after dpkg --add-architecture armhf ?

Apols as that is great to know, still scratching my head maybe it was just me and SLES as been certain I would have to compile Arm64 apps where they didn't exist.