09-13-2017, 03:49 PM
(09-12-2017, 09:39 AM)Farley56 Wrote: 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.
