ARMv6 support / Raspberry Pi

[mike admin]

Mike, I just went to test the 32-bit ARM support for the Gentoo package but I see that you've built it using the softfloat ABI, which is surprising. This fell out of use years ago. The only reason to use it now is for compatibility with old proprietary software but the world has moved on. It's not compatible with hardfloat systems so this isn't much use to anybody. Any chance you could respin it as a hardfloat binary?

MakeMKV uses (almost) NO floating point ops, so the image is made soft-float. It IS compatible with armhf, and should just work, as it is a subset of armhf. Please let me know the exact error you're getting...

[Chewi]

If I try to run it manually, I get this.

Code: Select all

chewi@utilite ~ $ makemkvcon 
-bash: /usr/bin/makemkvcon: No such file or directory

readelf reveals that it expects the ARM softfloat runtime linker known as ld-linux.so.3.

Code: Select all

chewi@utilite ~ $ readelf -d /usr/bin/makemkvcon 

Dynamic section at offset 0x5afee0 contains 32 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libmakemkv.so.1]
 0x00000001 (NEEDED)                     Shared library: [libdriveio.so.0]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x00000001 (NEEDED)                     Shared library: [ld-linux.so.3]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 ...

I don't have this library so I believe that's where the error comes from. The hardfloat equivalent is called ld-linux-armhf.so.3, which I do have. If I try to force it through this linker, it fails with a similar error.

Code: Select all

chewi@utilite ~ $ /lib/ld-linux-armhf.so.3 /usr/bin/makemkvcon 
/usr/bin/makemkvcon: error while loading shared libraries: /usr/bin/makemkvcon: internal error

If I create ld-linux.so.3 as a symlink to ld-linux-armhf.so.3, I get this.

Code: Select all

chewi@utilite ~ $ makemkvcon 
Segmentation fault

As I understand it, these are completely incompatible ABIs. Perhaps you built it with the compatibility option -mfloat-abi=softfp. That uses hardware floating point instructions but with the softfloat ABI, making it compatible with purely softfloat binaries. It is still incompatible with hardfloat binaries though. Debian explains this in more detail.

You probably built this for ARMv6 so that it would work on the Raspberry Pi 1 and Zero. Debian itself only distributes purely softfloat binaries for ARMv6 whereas its hardfloat binaries require ARMv7. However, Raspbian, which is based on Debian but targeted specifically at the Pi, distributes hardfloat binaries for ARMv6. Raspberry Pi 1 and Zero users simply would not use vanilla Debian for this reason. There is a considerable performance gain from using hardfloat binaries even over softfp binaries with hardware instructions.

[mike admin]

Thanks a lot for a detailed info. So, do we have armel devices at all? Should I build armel and armhf, or just drop armel in favor of armhf?

[Chewi]

The only ARMv6 devices that tend to get used these days are the Raspberry Pi 1 and Zero. Obviously people tend to go for the later Pi models but the Zero is still popular due to its tiny size. Every (or almost every?) ARMv7 device has hardware float instructions. In short, drop armel, just provide armhf.

[SnoopKatt]

If I try to run it manually, I get this.

Code: Select all

chewi@utilite ~ $ makemkvcon 
-bash: /usr/bin/makemkvcon: No such file or directory

readelf reveals that it expects the ARM softfloat runtime linker known as ld-linux.so.3.

Code: Select all

chewi@utilite ~ $ readelf -d /usr/bin/makemkvcon 

Dynamic section at offset 0x5afee0 contains 32 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libmakemkv.so.1]
 0x00000001 (NEEDED)                     Shared library: [libdriveio.so.0]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x00000001 (NEEDED)                     Shared library: [ld-linux.so.3]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 ...

I don't have this library so I believe that's where the error comes from. The hardfloat equivalent is called ld-linux-armhf.so.3, which I do have. If I try to force it through this linker, it fails with a similar error.

Code: Select all

chewi@utilite ~ $ /lib/ld-linux-armhf.so.3 /usr/bin/makemkvcon 
/usr/bin/makemkvcon: error while loading shared libraries: /usr/bin/makemkvcon: internal error

If I create ld-linux.so.3 as a symlink to ld-linux-armhf.so.3, I get this.

Code: Select all

chewi@utilite ~ $ makemkvcon 
Segmentation fault

As I understand it, these are completely incompatible ABIs. Perhaps you built it with the compatibility option -mfloat-abi=softfp. That uses hardware floating point instructions but with the softfloat ABI, making it compatible with purely softfloat binaries. It is still incompatible with hardfloat binaries though. Debian explains this in more detail.

You probably built this for ARMv6 so that it would work on the Raspberry Pi 1 and Zero. Debian itself only distributes purely softfloat binaries for ARMv6 whereas its hardfloat binaries require ARMv7. However, Raspbian, which is based on Debian but targeted specifically at the Pi, distributes hardfloat binaries for ARMv6. Raspberry Pi 1 and Zero users simply would not use vanilla Debian for this reason. There is a considerable performance gain from using hardfloat binaries even over softfp binaries with hardware instructions.

Hi,

I'm having the same issue as you. I tried following your steps but I wasn't able to get it working (I still get the same error). I updated the bin Makefile to point to armhf but when I try running makemkvcon it still looks like it's trying to pull in ld-linux.so.3. Could you elaborate on how exactly you fixed it please? Sorry if it's a dumb question - I'm still trying to learn my way around Linux. If it helps, I'm running Ubuntu on an Odroid XU4. Thanks!

[Chewi]

I'm sorry to say that I didn't fix it, I was only demonstrating how it is broken. Only Mike can fix this.

[SnoopKatt]

I'm sorry to say that I didn't fix it, I was only demonstrating how it is broken. Only Mike can fix this.

Gotcha. Thanks for replying. It'd be a great fix... I'm working on setting up a plex server on a single board computer and this is the only missing piece!

[xoocoon]

Hi there, today, I got this message when trying to execute the makemkvcon on the current OSMC on a Raspberry Pi 4B 4GB:

-bash: /usr/bin/makemkvcon: No such file or directory

makemkv-oss built just fine - no problems there.
OSMC runs on 64bit, so the target architecture aarch64/arm64, i.e. the message above is produced by the arm64 version of the makemkvcon binary. armel does not execute either as it fails when connecting to the (USB?) bus?

I would also appreciate an armhf for aarch64 build if this possible.

[Chewi]

arm64 shouldn't have this problem. What does this return?

Code: Select all

ls /lib*/ld*.so*

[xoocoon]

Thanks for the reply. It returns

/lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3

[Chewi]

Right, so you have a 32-bit system, despite you saying you have 64-bit hardware. You need the armhf version, not the arm64 version, if only an armhf version was provided by Mike.

[xoocoon]

Well, my reason for claiming an arm64/aarch64 setup is the output of

Code: Select all

uname -a

which is:

Code: Select all

Linux pi-4 5.10.78-2-osmc #1 SMP PREEMPT Wed Nov 17 04:52:11 UTC 2021 aarch64 GNU/Linux

Furthermore, in my config.txt (the Pi-specific BIOS setup file), I have the line

Code: Select all

arm_64bit=1

See https://www.raspberrypi.com/documentati ... #arm_64bit for reference.
But still, my bottom line is that I need an armhf build of makemkv-bin. @mike: Let me know if I can be of any help when it comes to testing.

[Chewi]

I'm not too familiar with the Pi, but you have a 64-bit kernel with a 32-bit userland. I'm not sure why they've done that on a 4GB board, but it's perfectly fine.

[xoocoon]

Thanks for the clarification, makes sense to me. (Although I do not know why OSMC is structured that way.)

[dtech]

Unfortunately, I struggle with the same issue under LibreELEC as Chewi, I'm using a 64-bit kernel with 32-bit userspace on an Amlogic S905D SoC (ARMv8-A). But I also tried it under Meson8m2 (S812) and Meson8B (S805), which are 32-bit ARMv7 SoCs. The armel binary doesn't work there either, and it produces Segmentation fault, probably due to the incompatible softfp abi.

I also tried under 64-bit userspace with the arm64 makemkvcon binary and it works without error, but unfortunately no one uses 64-bit userspace under LE on ARM, because the Widevine DRM required for streaming services, and it only works on 32 bits.

Somehow it would be nice to have a working armhf binary for 32-bit ARMv7 and above.