Linuxmusl arm64

[gpetrov]

first linuxmusl arm64 build

[lovell]

Thanks for the PR, I'd prefer that all the platforms/OSs provide the same set of dependencies, so we'll need to include librsvg.

Does this relate to the object name conflicts in archive: .libs/librsvg-2.lax/librsvg_c_api.a//deps/svg/./.libs/librsvg_c_api.a error you reported in #72 (comment) ? If so, that looks like a missing space, perhaps that helps you narrow down what could be causing it?

- .libs/librsvg-2.lax/librsvg_c_api.a//deps/svg/./.libs/librsvg_c_api.a
+ .libs/librsvg-2.lax/librsvg_c_api.a/ /deps/svg/./.libs/librsvg_c_api.a 

[gpetrov]

Switched to use the standard name linuxmusl-arm64v8 (note the v8 at the end) and made alias for linuxmusl-arm64

Also adjusted your GitHub build action.

But as for the librsvg the problem is that it is just already included by other package like probably mango, so it is already available. So the dependencies are the same, but in linuxmusl somehow librsvg is already included.

The compilation seems to go all fine now. At the end is reported:

make[1]: Leaving directory '/deps/vips'
libvips-cpp.so.42 depends on libvips.so.42
libstdc++.so.6 does not exist in /target/lib
libc.musl-aarch64.so.1 does not exist in /target/lib
libgcc_s.so.1 does not exist in /target/lib
libstdc++.so.6 does not exist in /target/lib
libc.musl-aarch64.so.1 does not exist in /target/lib
libgcc_s.so.1 does not exist in /target/lib
     8782077     8423595  95% /packaging/libvips-8.10.0-linuxmusl-arm64v8.tar.gz
     8782077     8423595  95%
09def5d943bb4ef498138e92c3b9931016b83aaabd05fa09e3d67af6b980012d  libvips-8.10.0-linuxmusl-arm64v8.tar.br
f3b512e996e0c2f53e67f51f056a27e2cec30725ef7386c125d473711dd20cc9  libvips-8.10.0-linuxmusl-arm64v8.tar.gz

Wasn't sure about the missing so, files but I think it is ok as those should be available system wide.

[lovell]

as for the librsvg the problem is that it is just already included by other package like probably mango, so it is already available.

This script needs to build librsvg as a static library and cannot rely on a shared library provided via package manager. Without it I suspect libvips is being built without support for SVG input. Do you have an example build log (e.g. GitHub Actions) you could share to verify this?

[gpetrov]

Here are two build logs, with and without librsvg. Second one fails. Hope you can spot the difference and have an idea for solution.

linuxmusl-arm64v8_no_librsvg.log
linuxmusl-arm64v8_with_librsvg.log

[lovell]

The first log file includes the following lines that state libvips was built without support for librsvg:

checking for RSVG... no
configure: WARNING: librsvg-2.0 >= 2.40.3 or cairo >= 1.2 not found; disabling SVG load via rsvg

Please can you update this PR to include librsvg, even if there is an error, and we try to can work back from there.

[gpetrov]

done it should build now with librsvg as it used to be. Maybe this will go just fine in the building actions as they are running on new instances.

I would suggest to eventually switch to docker buildx building as GitHub Actions, as it is much cleaner, like what is suggested for sqllite3: TryGhost/node-sqlite3#1362

[lovell]

Please can this be adapted to cross-compile for the aarch64-unknown-linux-musl host (see the existing linux-arm64v8 directory for example settings that can be adapted).

[gpetrov]

@lovell sorry for the delay, hope it is ok now.

[lovell]

Thanks for the updates, I can see cross-compilation settings for rust but not for the rest of the (C-based) dependencies. Am I missing something? Perhaps we could use one of the toolchains from https://musl.cc/ ? These are available as Docker images for running on Intel hardware - muslcc/i686:aarch64-linux-musl might be appropriate.

[lovell]

Do we still need these aliases? It looks like using linuxmusl-arm64v8 as the PLATFORM might be sufficient.

[gpetrov]

sorry @lovell this is a bit above my head... feel free to pickup the changes further.

I'm also still getting the libtool error on librsvg.. tried about everything but can't really find a solution. It happens to me btw also on the regular linux-arm64v8

Compiling librsvg_c_api v0.0.1 (/deps/svg/librsvg)
    Finished release [optimized] target(s) in 1m 10s
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD     librsvg-2.la
libtool:   error: object name conflicts in archive: .libs/librsvg-2.lax/librsvg_c_api.a//deps/svg/./.libs/librsvg_c_api.a
make[3]: *** [Makefile:998: librsvg-2.la] Error 1

[michtio]

@lovell @gpetrov is there any progress on this issue? ARM linux builds are getting more and more popular out there. I almost got all build systems running, just this one is currently a blocker with optipng-bin.

Thanks!

[lovell]

I've started a work-in-progress branch at https://github.com/lovell/sharp-libvips/tree/add-linuxmusl-arm64v8 that uses a complete cross-compiler toolchain so we can generate linuxmusl-arm64v8 binaries on x64 hardware.

Sadly it doesn't work yet because... surprise... it runs into the same original problem with librsvg that @gpetrov ran into with native compilation:

libtool:   error: object name conflicts in archive: .libs/librsvg-2.lax/librsvg_c_api.a//deps/svg/./.libs/librsvg_c_api.a

My best guess is that this relates to the (lack of?) libtool sysroot, but it needs more investigation.

[kleisauke]

This is basically what libtool does:

AR=aarch64-linux-musl-ar
f_ex_an_ar_dir=.libs/librsvg-2.lax/librsvg_c_api.a/
f_ex_an_ar_oldlib=/deps/svg/./.libs/librsvg_c_api.a

if ($AR t "$f_ex_an_ar_oldlib" | sort | sort -uc >/dev/null 2>&1); then
 :
else
  echo "object name conflicts in archive: $f_ex_an_ar_dir/$f_ex_an_ar_oldlib" >&2
fi

So, it checks whether the contents of the librsvg_c_api.a archive does not contain duplicates.

Comparing the diff between the output of $AR t "$f_ex_an_ar_oldlib" | sort and $AR t "$f_ex_an_ar_oldlib" | sort -uc reveals:

diff --git a/librsvg_c_api-sort.a b/librsvg_c_api-sort-unique.a
index 1111111..2222222 100644
--- a/librsvg_c_api-sort.a
+++ b/librsvg_c_api-sort-unique.a
@@ -164,7 +164,6 @@ floatsitf.o
 floatunditf.o
 floatunsitf.o
 fp_mode.o
-fp_mode.o
 int_util.o
 muldc3.o
 mulsc3.o

Notice that fp_mode.o is listed there twice. The reason for this is that probably one fp_mode.o originates from Rust and the other from musl.

I'm looking for a way to fix this. Perhaps it needs a similar hack as the now-reverted GNOME/librsvg@4162693 commit.

[lovell]

Great work, here's the relevant logic in rustc that affects the aarch64 and musl combo:

https://github.com/rust-lang/compiler-builtins/blob/e6fd1b272ff4cc34810e20126ffe17888a708f39/build.rs#L400-L433

[kleisauke]

I noticed that too. I'm now building with export CFLAGS_aarch64_unknown_linux_musl="+nofp" to exclude these floating point intrinsics from Rust, hopefully that will work.

[kleisauke]

This commit seems to fix it for me: kleisauke@9f54bfd, see the relevant GitHub actions build:
https://github.com/kleisauke/libvips-packaging/runs/1955112764

Unfortunately, this requires a nightly version of Rust (due to the -Zbuild-std feature flag), perhaps the hack mentioned above would have been a better way to resolve the failing librsvg build.

[lovell]

@kleisauke Thank you! I'm OK with the use of nightly rust. Feel free to add this commit to the add-linuxmusl-arm64v8 branch, or roll it all up into a single PR, whatever is easiest.

Thanks too for improving the (rather hacked together) toolchain filesystem paths. I'll remove the offending /usr symlink from the aarch64-linux-musl-crosstools-main repo.

I'll add a native ARM64 linuxmusl-arm64v8 Travis CI environment to sharp so we can test the output. There are possible ABI differences between musl 1.1.x (Alpine 3.11, as used by all the official Node docker images) and 1.2.x (as used by the toolchain) that we might yet run into.

[kleisauke]

I just opened #90. Thanks for removing the /usr symlink!