Build sharp for non-amd64 architectures #293
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On non-amd64 architectures, the default version of
sharp
may not automatically install due to a missing copy oflibvips
. This is referred to in PR #281 and issues #264 and #267. However whilst #281 fixes the images so they build and run,sharp
may still not be built. It's an optional dependency and ghost works fine without it.This PR is to get
libvips
installed, andsharp
installed and built.On Alpine, we upgrade to 3.15 (was 3.14). This gives us libvips 8.12.1-r0 (link to Alpine package search) which is sufficient to build the current dependency version of sharp (0.29.0).
The main caveat of the Alpine change is, we'll be upgrading from 3.14 to 3.15. This may require across-the-board testing.
On Debian, we currently use the bullseye image version. However the bullseye version of libvips-dev (8.10.5-2) isn't recent enough (link to Debian package search). So we download and build libvips-dev from Debian bookworm, which brings us version 8.12.1-1. (We also download and build libcgif-dev, since that prerequisite isn't available in bullseye.)
Note that on Debian we download and build the packages from source, targeting the bullseye runtime. This is likely to give better compatibility versus simply installing the official bookworm packages, which may require updated components.
I've only tested this on my 32-bit Raspberry Pi (armv7). Happy to take advice on how to get this PR ready for merging. Thanks!