Raspbian 64-bit compilation failed

[174n]

The compilation on 64-bit Rapbian took unreasonably long time and failed at the end. I didn't found any cross-compile build scripts for arm/arm64 in the repo, is it supposed to be built on Raspberry Pi? On my Raspberry Pi 3 it took more than 5 hours and didn't even succeed

cargo build --release --features partially-static
warning: field is never read: max_size
  --> crates/collection/src/legacy_pos.rs:30:5
   |
30 |     pub max_size: usize,
   |     ^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(dead_code)] on by default

warning: field is never read: max_groups
  --> crates/collection/src/legacy_pos.rs:31:5
   |
31 |     pub max_groups: usize,
   |     ^^^^^^^^^^^^^^^^^^^^^

warning: collection (lib) generated 2 warnings
   Compiling audioserve v0.17.1 (/home/ivan/audioserve)
error: could not compile audioserve

Caused by:
  process didn't exit successfully: rustc --crate-name audioserve --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=3 -C lto -C codegen-units=1 --cfg 'feature="async-tar"' --cfg 'feature="async-zip"' --cfg 'feature="behind-proxy"' --cfg 'feature="chrono"' --cfg 'feature="cron"' --cfg 'feature="default"' --cfg 'feature="folder-download"' --cfg 'feature="native-tls"' --cfg 'feature="partially-static"' --cfg 'feature="proxy-headers"' --cfg 'feature="shared-positions"' --cfg 'feature="symlinks"' --cfg 'feature="tls"' --cfg 'feature="tokio-native-tls"' --cfg 'feature="websock"' -C metadata=2860120b6c7e0d81 -C extra-filename=-2860120b6c7e0d81 --out-dir /home/ivan/audioserve/target/release/deps -L dependency=/home/ivan/audioserve/target/release/deps --extern anyhow=/home/ivan/audioserve/target/release/deps/libanyhow-276d9a184d92698e.rlib --extern async_tar=/home/ivan/audioserve/target/release/deps/libasync_tar-26aef9e92db5a10d.rlib --extern async_zip=/home/ivan/audioserve/target/release/deps/libasync_zip-7ec3ab6e2fe25ce1.rlib --extern bytes=/home/ivan/audioserve/target/release/deps/libbytes-d572020dcfc4a0d1.rlib --extern chrono=/home/ivan/audioserve/target/release/deps/libchrono-7c7ad26673f6b4d3.rlib --extern clap=/home/ivan/audioserve/target/release/deps/libclap-692117982c8be36a.rlib --extern collection=/home/ivan/audioserve/target/release/deps/libcollection-9957c1a2f34624a2.rlib --extern cron=/home/ivan/audioserve/target/release/deps/libcron-c18e01a37ccec476.rlib --extern csv=/home/ivan/audioserve/target/release/deps/libcsv-450d8a493eae1e7a.rlib --extern data_encoding=/home/ivan/audioserve/target/release/deps/libdata_encoding-cd76fc69adea8480.rlib --extern dirs=/home/ivan/audioserve/target/release/deps/libdirs-30268afa9bf8e5d9.rlib --extern env_logger=/home/ivan/audioserve/target/release/deps/libenv_logger-78c6c188506f9942.rlib --extern futures=/home/ivan/audioserve/target/release/deps/libfutures-71cb610fd6583228.rlib --extern headers=/home/ivan/audioserve/target/release/deps/libheaders-8ecd14bb7e80f308.rlib --extern hyper=/home/ivan/audioserve/target/release/deps/libhyper-80c35cce8602948a.rlib --extern lazy_static=/home/ivan/audioserve/target/release/deps/liblazy_static-aac7bb76c0b45d97.rlib --extern leaky_cauldron=/home/ivan/audioserve/target/release/deps/libleaky_cauldron-afb0808268331cc6.rlib --extern linked_hash_map=/home/ivan/audioserve/target/release/deps/liblinked_hash_map-b20bb9d09a3a1102.rlib --extern log=/home/ivan/audioserve/target/release/deps/liblog-a96e95a01537cd9a.rlib --extern mime=/home/ivan/audioserve/target/release/deps/libmime-0a24e1ba103da365.rlib --extern native_tls=/home/ivan/audioserve/target/release/deps/libnative_tls-947cc697e9b50567.rlib --extern nix=/home/ivan/audioserve/target/release/deps/libnix-932ff677bca8fb44.rlib --extern num_cpus=/home/ivan/audioserve/target/release/deps/libnum_cpus-9f0183789de366f7.rlib --extern percent_encoding=/home/ivan/audioserve/target/release/deps/libpercent_encoding-09aeb25ecc82db7a.rlib --extern proxy_headers=/home/ivan/audioserve/target/release/deps/libproxy_headers-3c9f1b157b8b2850.rlib --extern regex=/home/ivan/audioserve/target/release/deps/libregex-d77ad295ad8f8d89.rlib --extern ring=/home/ivan/audioserve/target/release/deps/libring-f3f5186f23cc4e03.rlib --extern serde=/home/ivan/audioserve/target/release/deps/libserde-a02a3102c02d4866.rlib --externserde_derive=/home/ivan/audioserve/target/release/deps/libserde_derive-6d8720efd22c01ee.so --extern serde_json=/home/ivan/audioserve/target/release/deps/libserde_json-ba65da9ba45ed3c5.rlib --extern serde_yaml=/home/ivan/audioserve/target/release/deps/libserde_yaml-852e4018d8048dbf.rlib --extern thiserror=/home/ivan/audioserve/target/release/deps/libthiserror-5535ecf4a0571022.rlib --extern tokio=/home/ivan/audioserve/target/release/deps/libtokio-200be3e5139c8cc3.rlib --extern tokio_native_tls=/home/ivan/audioserve/target/release/deps/libtokio_native_tls-8504518167cfa7e1.rlib --extern url=/home/ivan/audioserve/target/release/deps/liburl-b6246dc0d4296906.rlib --extern websock=/home/ivan/audioserve/target/release/deps/libwebsock-8d8824e157d7a948.rlib -L native=/home/ivan/audioserve/target/release/build/media_info-d1c5f237918ea69f/out/ffmpeg-4.3.1/libavformat -L native=/home/ivan/audioserve/target/release/build/media_info-d1c5f237918ea69f/out/ffmpeg-4.3.1/libavutil -L native=/home/ivan/audioserve/target/release/build/media_info-d1c5f237918ea69f/out/ffmpeg-4.3.1/libavcodec -L native=/home/ivan/audioserve/target/release/build/ring-50386abfa8df3669/out -L native=/home/ivan/audioserve/target/release/build/zstd-sys-3dbadd08fbb3d768/out (signal: 9, SIGKILL: kill)

[izderadicka]

Hi, if you look at final rustc problem it was caused because something (system?) has killed rustc. Together with very long compilation time it may show for lack of memory. How much memory is on your system. Compiler are used to be rather demanding on memory.
At home I'm compiling on quite low end computer (old Celeron with 4GB mem), but significantly less memory I guess might be problem.

I have never tried RP platform, so cannot help much, also do not have experiences with cross-compile for arm64

You can also try couple of things:

1. Do not use --features partially-static - this downloads an compiles ffmpeg libav, which is quite complex task, theoretically you might be able to use dynamically links libraries if you match right version.
2. Do not use --release - release optimization is quite expensive in rustc.

Though these two tips will not probably help to finally resolve the issue they can at least help to identify problem.

Ultimate solution might be cross-compile, but I suspect it could be complex due to dependencies on native libraries like libssl and libav

[srd424]

I looked at trying to resurrect https://github.com/greencashew/audioserve for arm builds, but that uses qemu-user to run cargo, and that now seems to die due to lack of memory both on github actions and trying to build locally on my machine outside of docker.

I have managed to get rust to crossbuild, first stab at a docker builder image is here: https://github.com/srd424/audioserve-builder https://codeberg.org/srd424/audioserve-builder - I need to figure out how to integrate it into the normal audioserve build scripts, and it doesn't build the client yet, but you can at least get a binary out of it, and it proves it's possible!

[srd424]

There are now some aarch64 binaries, but they're debug at the moment (the client is now built though):

https://github.com/srd424/audioserve-builder/releases/

(they're not yet statically linked, so they'll need dropping probably into a recent Debian/Ubuntu system/rootfs/container, and libavformat58 at least will need installing.)

There's also a github hosted version of the builder image that can be pulled:

docker pull ghcr.io/srd424/audioserve-builder:latest

Edit: actual code has moved to codeberg.org/srd424/audioserve-builder - the binaries and container images are still on GH at the moment though. Actions are currently not running automatically - poke me if you need me to rebuild anything.

[srd424]

First stab at an aarch64 docker image, includes client and SSL key - not as yet extensively tested, but the basics seem to work when run under qemu:

docker pull ghcr.io/srd424/audioserve-docker:latest

Edit: actual code has moved to codeberg.org/srd424/audioserve-builder - the binaries and container images are still on GH at the moment though. Actions are currently not running automatically - poke me if you need me to rebuild anything.

[uGeek]

But... what would a docker-compose look like for the latest version of audioserve for Raspberry Pi with arm64?

[srd424]

Not sure as I don't use docker/podman compose, but should be reasonably trivial? Latest version should be https://github.com/srd424/audioserve-docker/pkgs/container/audioserve-docker/41247387?tag=v0.22.0 but I haven't tested it yet, and I don't think it builds the new web client yet either..

[izderadicka]

docker-compose would be same I think. It just runs the container. But of course you'll need docker and docker-compose for this platform

…

On Mon, Sep 12, 2022, 18:51 uGeek ***@***.***> wrote: But... what would a docker-compose look like for the latest version of audioserve for Raspberry Pi with arm64? — Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQVUBNLNIR2NVJDUDI7PQLV55NPTANCNFSM5OLMXPPQ> . You are receiving this because you commented.Message ID: ***@***.***>

[srd424]

The following lightly modified from the upstream example should do it - I've dropped PUID/PGID stuff because I'm not sure that does anything (or ever did):

version: "3"

services:
  audioserve:
    image: ghcr.io/srd424/audioserve-docker:v0.22.0
    restart: unless-stopped
    command: --tags /audiobooks
    environment:
      - "AUDIOSERVE_SHARED_SECRET=VGM4oDS6wGKge9"
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - "./config:/home/audioserve/.audioserve"
      - "/path/to/Audio/Books:/audiobooks"

[uGeek]

Not sure as I don't use docker/podman compose, but should be reasonably trivial? Latest version should be https://github.com/srd424/audioserve-docker/pkgs/container/audioserve-docker/41247387?tag=v0.22.0 but I haven't tested it yet, and I don't think it builds the new web client yet either..

Yes, As you comment, the interface still hasn't changed. The client remains the same, but when I look at the version it is up to date

[uGeek]

The following lightly modified from the upstream example should do it - I've dropped PUID/PGID stuff because I'm not sure that does anything (or ever did):

version: "3"

services:
  audioserve:
    image: ghcr.io/srd424/audioserve-docker:v0.22.0
    restart: unless-stopped
    command: --tags /audiobooks
    environment:
      - "AUDIOSERVE_SHARED_SECRET=VGM4oDS6wGKge9"
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - "./config:/home/audioserve/.audioserve"
      - "/path/to/Audio/Books:/audiobooks"

Thanks a lot. I have tested on my vps with arm64 architecture and it works perfectly. But on my Raspberry Pi with arm64 architecture it doesn't work

[srd424]

Can you open an issue on https://github.com/srd424/audioserve-docker so we don't spam @izderadicka unnecessarily?

[srd424]

Just to note I've moved the actual code for my aarch64 builder image to codeberg.org/srd424/audioserve-builder - the binaries and container images are still on GH at the moment though. Actions are currently not running automatically - poke me if you need me to rebuild anything.