Fix cross compilation for armv6hf (Raspberry Pi 1)

[starypatyk]

The Docker image intended to cross-compile librespot for armv6hf (i.e. Raspberry Pi 1) did not work for some time.

Changes proposed here attempt to fix this:

• Commit faeaf50 changes the default tls library from aws-lc-rs to ring as suggested by @kingosticks in Avoid using default features of dependencies #1382 (commit: kingosticks@24bbc63). I tried to compile aws-lc-rs for armv6hf, but did not succeed. 😞 I understand that this change might be controversial - I am open to discuss this. Reverted in 6bb009a
• Commit 0f497cc adds with-libmdns to the list of features - to compensate for the changes made in Discovery: Refactor and add Avahi DBus backend #1347.
• Commit 3026d03 is just a small clean-up of the Docker image and the script used to build librespot.
• Commit 765f1f2 fixes build of the aws-lc-rs library.
• Commit ab1102a fixes a minor issue in binaries generated via Docker for other platforms (VERGEN_IDEMPOTENT_OUTPUT instead of actual git commit hash)

With these changes in place I have been able to cross-compile librespot for armv6hf and verify that it runs as expected on a Raspberry Pi 1.

I have also verified builds using Docker for aarch64 and x86_64.

[kingosticks]

I've not tried to compile for pi 1 lately but I would be extremely surprised if switching to ring is a requirement for that to work. It never used to be.

I think we should put the default back to ring. I have been meaning to get back to that PR but I really don't think it should be merged in as part of this, it's too much of a big change.

[starypatyk]

I've not tried to compile for pi 1 lately but I would be extremely surprised if switching to ring is a requirement for that to work. It never used to be.

After installing cmake (from system packages) and bindgen-cli (using cargo) I got to the point of missing libclang.

Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-*.so', 'libclang.so.*', 'libclang-*.so.*'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"

I have not been able to find libclang in the set of armv6hf packages used by the Dockerfile. An alternative might be to use e.g. these tools (https://github.com/tttapa/docker-arm-cross-toolchain) instead. But I have not tried this yet.

I think we should put the default back to ring. I have been meaning to get back to that PR but I really don't think it should be merged in as part of this, it's too much of a big change.

Fair enough - I can remove this change from this PR and wait for another PR that will make this explicit.

[kingosticks]

It might be missing apt install clang libclang-dev ? Might as well update the base image, 18.04 is ridiculous.

[starypatyk]

It might be missing apt install clang libclang-dev ?

Tried that - got a different error this time:

  bindgen-STDERR: /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
  Unable to generate bindings: clang diagnosed error: /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found

I suspected that libclang is required for the target architecture, not for the architecture used on the build host.

Might as well update the base image, 18.04 is ridiculous.

Indeed - I did not want to start with major changes.

[kingosticks]

Bindgen is used to generate rust code (not binaries) from c headers, I'd have thought it would be fine with the host version. But it does need to have the target's c system (not clang) headers to do this task, think that might be the problem. Where are they provided? In the PI tools sysroot or from apt?

[kingosticks]

But to be honest, you are right. It's a waste of time fighting aws-lc all the time. Let's see if we can switch to ring as default and make everyone's lives 10x easier.

[starypatyk]

Bindgen is used to generate rust code (not binaries) from c headers, I'd have thought it would be fine with the host version. But it does need to have the target's c system (not clang) headers to do this task, think that might be the problem. Where are they provided? In the PI tools sysroot or from apt?

@kingosticks - thanks for this tip. I have finally managed to cross-compile aws-lc-rs. 👍

Setting BINDGEN_EXTRA_CLANG_ARGS environment variable did the trick - I have found it here: https://crates.io/crates/bindgen-cli

The compiled librespot binary seems to run on a Raspberry Pi 1.

I am not sure if it makes sense to include required changes in this PR. Maybe I will clean them up and submit - just in case. 🤔

[roderickvd]

It used to be ring before. Switching to aws-lc must have happened by me merging a Docker PR and not being aware of the implications. We don’t need the FIPS compliance and certainly not the hard time that it’s giving us.

[starypatyk]

It used to be ring before. Switching to aws-lc must have happened by me merging a Docker PR and not being aware of the implications. We don’t need the FIPS compliance and certainly not the hard time that it’s giving us.

Apparently this has been changed upstream in hyper-rustls at 0.27.0 release:

Default cryptography provider changed to aws-lc-rs to match upstream Rustls project. Note that this has some implications on platform support and build-time tool requirements such as cmake on all platforms and nasm on Windows.
Support for ring continues to be available: set the ring crate feature.

[starypatyk]

Since I have found a way to build aws-lc-rs for armv6hf, I have reverted the change of the default TLS library to leave it for a separate explicit PR.

Brief summary of changes required to build aws-lc-rs (might help someone in the future):

• Install additional system packages cmake, clang and libclang-dev.
• Install bindgen (cargo install --force --locked bindgen-cli)
• Set BINDGEN_EXTRA_CLANG_ARGS environment variable to point to sysroot for relevant target architecture.

I have also added git to the packages in the contrib/Dockerfile to fix a minor issue - to have correct commit hash rather than VERGEN_IDEMPOTENT_OUTPUT when checking version of the resulting binary.

I do not plan any more changes to this PR - unless there are further comments/suggestions.