Support Raspberry Pi or Linux-arm ？

[chaoweiyi]

Can it be supported in the next version?

[dlemstra]

I don't know what needs to be done to make this possible. I can take a look at it but I don't think that support can be added before the next release.

[chaoweiyi]

I appreciate your help.

[dlemstra]

Looks like we need to wait till support for building on ARM will be added to AzureDevOps. Once that has been added I will take another look at this issue.

[PatrykPorabik]

Hello,
Any news when arm64 will be supported? We've tried to install our app with your library on Raspberry, Ubuntu 18.04 with arm64 processor, but we failed. Do you know the estimates when it will be possible?

[dlemstra]

I cannot give you an estimate because this all depends on when AzureDevOps will have arm64 support. And at this moment it has no support for that.

[nixcamic]

AFAIK AzureDevOps now has support for arm64. arm/arm64 would also be super useful for Xamarin.Android projects.

[dlemstra]

The build has moved from AzureDevOps to GitHub. Not sure if they support an ARM build.

[nixcamic]

AFAIK they claim to support ARM. If I knew more about the GitHub build process I would test it myself.

[he852100]

I seem to need it.

[derBobo]

are there any news for an arm/arm64 build ?

[rosenbjerg]

I would also like arm32 and arm64 support

[dlemstra]

Waiting for ARM support in GitHub actions for the open source developers.

[rosenbjerg]

You can build ARM images on the GitHub build agents using Docker buildx/Docker experimental features.
See crazy-max/ghaction-docker-buildx
Docker then uses qemu for arm32 and arm64

[marshalhayes]

I stumbled upon this issue while trying to get the library working on my Raspberry Pi 4b. Everything ran extremely smoothly on my MacBook pro, so I was surprised it didn't on Linux.

My Raspberry Pi 4b is running a 64-bit version of Debian, but I think I'm having similar issues to everyone here: The library dll is passed along in my deployment process, but performing any operations with it throws a System.DllNotFoundException exception and sometimes a System.BadImageFormatException.

I assume this is related to support for arm64 processors?

marshal@rpi1:~$ uname -a
Linux rpi1 5.7.0-2-arm64 #1 SMP Debian 5.7.10-1 (2020-07-26) aarch64 GNU/Linu

Are there any steps I can take to get this working, or do I need to wait until GitHub actions supports ARM processors?

[dlemstra]

For this to work I will need to do an arm64 build of the Magick.Native library. The complete build has now moved to GitHub and we need to wait till they will provide support for the open source projects.

[nixcamic]

For stuff I absolutely need to run cross platform I switched over to ImageSharp, it's not as well documented or as fast, but it seems pretty feature complete and is 100% managed code so will run anywhere .NET/Mono does.

[Y56380X]

I tried to cross-compile Magick.Native for ARM64 on an Ubuntu x64 machine and copy the .so file manually. It kind of works for my purposes but some dependencies failed to build properly. (Forked for build script adjustments to Y56380X/Magick.Native)

Failing dependencies:

• openjpeg
• glib
• lqr
• pango
• croco
• librsvg

[Seabizkit]

Please add this..... busy setting up a project now and converting to Arm, and was kind stomped back when this is not working.

is there an ETA? Please give this some LOVE

[dlemstra]

You will need to ask GitHub for the ETA. Read my response:

For this to work I will need to do an arm64 build of the Magick.Native library. The complete build has now moved to GitHub and we need to wait till they will provide support for the open source projects.

[EraYaN]

It is feasible (and probably faster) approach to building ARM anything to run a cross compile, like for example something like this:

https://github.com/jellyfin/jellyfin-skiasharp-native/tree/master/Jellyfin.SkiaSharp.NativeAssets.LinuxArm

Don't think you need to run specifically on ARM to compile for it.

[barrct]

So instead of waiting for Azure and GitHub to be able to compile arm, can the ones of us that HAVE arm processors get the source to compile natively so that we can use this amazing tool that works so well on Intel chips?

We can compile the entire CLI on arm without issue, can we get direction on what needs cloned and locally compiled so that this can be used?

[dlemstra]

If you want to build Magick.NET with ARM support on your local machine you will need to clone this repository: https://github.com/dlemstra/Magick.Native. There are no instruction on how to build it with ARM support but you could probably follow the build steps on Linux.

[barrct]

Alright, so following the suggestion from @dlemstra I have some notes.

1. The process does not work with the cloned repo as of 2021/10/21. There are issues in the install.dependencies.sh script, please see the issue Referenced package cannot be installed (python-pip) Magick.Native#12
   Fixing the issues is quite simple. You just need to remove the python-pip package, but you will also need to add a couple of other packages that my install did not seem to have available when needed in the later steps cmake meson libxml2-dev libxslt-dev. Additionally, the gcc-7 and g++-7 need converted to gcc and g++ as apt install was reporting them as depreciated.
   This is the final edited script that was able to allow for a clean compile on an INTEL processor (before I tried to move to the ARM)

This is my install.dependencies.sh now what give me a clean compile on Ubuntu x86.

---

#!/bin/bash
set -e

apt-get update -y

#apt-get install -y autoconf autopoint gettext git gperf libtool nasm pkg-config python python-pip python3-pip ragel software-properties-common texinfo
apt-get install -y autoconf autopoint gettext git gperf libtool nasm pkg-config python python3-pip ragel software-properties-common texinfo cmake meson libxml2-dev libxslt-dev

#add-apt-repository ppa:ubuntu-toolchain-r/test -y
apt-get update -y
#apt-get install gcc-7 g++-7 -y
apt-get install gcc g++ -y
#update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 60 --slave /usr/bin/g++ g++ /usr/bin/g++-7
#update-alternatives --config gcc

pip3 install cmake
pip3 install meson==0.55.3
pip3 install ninja==1.10.0.post2

---

2. This would be the commands to run in order for the clean compile in an x86 chip.
   sudo apt install git
   sudo git clone https://github.com/dlemstra/Magick.Native.git
   -= Fix the install.dependencies.sh script =-
   vi Magick.Native/build/linux/install.dependencies.sh
   -= Fix the install.dependencies.sh script =-
   cd Magick.Native/build/linux
   sudo ./install.dependencies.sh linux
   cd ../../src/ImageMagick/
   sudo ./checkout.sh linux ../../../artifacts
   cd libraries/
   sudo ../../../build/linux/build.libraries.sh ../../../build/libraries
   cd ../../../src/ImageMagick/libraries/
   sudo ../../../build/linux/build.ImageMagick.sh
   cd ../../Magick.Native/
   sudo ../../build/linux/build.Native.sh

You now have compiled objects.

ls Q16
CMakeCache.txt CMakeFiles cmake_install.cmake libMagick.Native-Q16-x64.dll.so Makefile

file Q16/libMagick.Native-Q16-x64.dll.so
Q16/libMagick.Native-Q16-x64.dll.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=8153f0576df8bfc6c77602db11b1db51aecf41a7, with debug_info, not stripped

That was on Ubuntu.
uname -a
Linux 5.13.0-20-generic #20-Ubuntu SMP Fri Oct 15 14:21:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Debian doesn't seem to be very happy.
uname -a
Linux barr-debian 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
./install.dependencies.sh
Hit:1 http://security.debian.org/debian-security bullseye-security InRelease
Hit:2 http://deb.debian.org/debian bullseye InRelease
Hit:3 http://deb.debian.org/debian bullseye-updates InRelease
Ign:4 http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu jammy InRelease
Err:5 http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu jammy Release
404 Not Found [IP: 91.189.95.85 80]
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu jammy Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Now, I can't say that they are 100% stable as right now I'm focusing on getting a clean build process to replicate on the Raspbery Pi.

3. So, you ask.... "If that worked on the x86, how did it go on the Pi?"
   Eh, not great.

When compiling the libraries, there's an error.

libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I/usr/local/include -I. -I../include -Iinclude -I../src -O3 -fPIC -MT src/arm/sysv.lo -MD -MP -MF src/arm/.deps/sysv.Tpo -c ../src/arm/sysv.S -o src/arm/sysv.o
../src/arm/sysv.S: Assembler messages:
../src/arm/sysv.S:399: conditional infixes are deprecated in unified syntax
../src/arm/sysv.S:410: Error: undefined symbol FFI_TYPE_STRUCT_VFP_FLOAT used as an immediate value
../src/arm/sysv.S:411: Error: undefined symbol FFI_TYPE_STRUCT_VFP_DOUBLE used as an immediate value
../src/arm/sysv.S:450: Error: undefined symbol FFI_TYPE_STRUCT_VFP_FLOAT used as an immediate value
../src/arm/sysv.S:453: Error: undefined symbol FFI_TYPE_STRUCT_VFP_DOUBLE used as an immediate value
make[2]: *** [Makefile:1401: src/arm/sysv.lo] Error 1
make[2]: Leaving directory '/root/Magick.Native/src/ImageMagick/libraries/ffi/armv7l-unknown-linux-gnueabihf'
make[1]: *** [Makefile:1659: install-recursive] Error 1
make[1]: Leaving directory '/root/Magick.Native/src/ImageMagick/libraries/ffi/armv7l-unknown-linux-gnueabihf'
make: *** [Makefile:3237: install] Error 2

Then compiling ImageMagick

/usr/bin/mkdir -p '/usr/local/share/ImageMagick-7'
/usr/bin/install -c -m 644 config/english.xml config/francais.xml config/locale.xml '/usr/local/share/ImageMagick-7'
/usr/bin/mkdir -p '/usr/local/lib/ImageMagick-7.1.0/config-Q16HDRI'
/usr/bin/install -c -m 644 config/configure.xml '/usr/local/lib/ImageMagick-7.1.0/config-Q16HDRI'
/usr/bin/mkdir -p '/usr/local/lib/pkgconfig'
/usr/bin/install -c -m 644 MagickCore/ImageMagick.pc MagickCore/ImageMagick-7.Q16HDRI.pc MagickCore/MagickCore.pc MagickCore/MagickCore-7.Q16HDRI.pc MagickW and/MagickWand.pc MagickWand/MagickWand-7.Q16HDRI.pc '/usr/local/lib/pkgconfig'
make[2]: Leaving directory '/root/Magick.Native/src/ImageMagick/libraries/ImageMagick'
make[1]: Leaving directory '/root/Magick.Native/src/ImageMagick/libraries/ImageMagick'
mkdir: cannot create directory ‘/usr/local/include/ImageMagick-7/coders’: File exists

And then Magick.Native.

[ 95%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Types/TypeMetric.c.o
[ 97%] Building CXX object CMakeFiles/Magick.Native-Q8-x64.dll.dir/foo.cxx.o
make[2]: *** No rule to make target '/usr/local/lib//liblqr-1.a', needed by 'libMagick.Native-Q8-x64.dll.so'. Stop.
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/Magick.Native-Q8-x64.dll.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

I'm guessing the failing libraries can be skipped, but if anyone has thoughts on the main ImageMagick and Magick.Native, I'd love to hear them so that we can maybe get a ARM object for Apples and Pis.
Since she compiles on x86/Ubuntu, I'm not sure if figureing out how to cross-compile it to ARM64 is the answer or if the best option is to start to see why Raspi doesn't like it, possibly becuase of it's Debian backgroud since Debian can't compile the x86 version.
I will start to work though the library errors and see if clearing that up helps ImageMagick compile.
If anyone has cross-compiled before since I never have, that might be the solution as it seems to work on the X86 OS.

[barrct]

Alright, so after working on this between other projects I have some updates.
I can get everything to work to the point of compiling Magick.Native so to get to that point, just follow these steps.

---

sudo apt install git
sudo git clone https://github.com/dlemstra/Magick.Native.git

-= Remove the failing libraries and Fix the install.dependencies.sh script=-
vi Magick.Native/build/linux/build.libraries.sh
#$1/build.libxml.sh
#$1/build.fontconfig.sh
#$1/build.openexr.sh
#$1/build.ffi.sh
#$1/build.lqr.sh

vi Magick.Native/build/linux/install.dependencies.sh
#apt-get install -y autoconf autopoint gettext git gperf libtool nasm pkg-config python python-pip python3-pip ragel software-properties-common texinfo
apt-get install -y autoconf autopoint gettext git gperf libtool nasm pkg-config python python3-pip ragel software-properties-common texinfo cmake meson libxml2-dev libxslt-dev

#add-apt-repository ppa:ubuntu-toolchain-r/test -y
apt-get update -y
#apt-get install gcc-7 g++-7 -y
apt-get install gcc g++ -y
#update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 60 --slave /usr/bin/g++ g++ /usr/bin/g++-7
#update-alternatives --config gcc
-= Remove the failing libraries and Fix the install.dependencies.sh script=-

cd Magick.Native/build/linux
sudo ./install.dependencies.sh linux
cd ../../src/ImageMagick/
sudo ./checkout.sh linux ../../../artifacts
cd libraries/
sudo ../../../build/linux/build.libraries.sh ../../../build/libraries
cd ../../../src/ImageMagick/libraries/
sudo ../../../build/linux/build.ImageMagick.sh
cd ../../Magick.Native/
sudo ../../build/linux/build.Native.sh

---

Following that fixes all of the errors when compiling directly on the ARM Raspbery Pi through ../../../build/linux/build.ImageMagick.sh.
The last build step is ../../build/linux/build.Native.sh
Unfortunately this is failing and I don't know the Image Magick build process well enough to know where to look.

This also means that the system needs to be considerably more complicated as we now have to offload 100% of the processing to a separate server. In our case we are now in the process of moving all image processing to AWS Lambda functions. The plan is now to

1. On the Pi, Invoke the Lambda
2. Have it load the images from the API calls that it needs to process
3. Store the processed images into S3
4. Return an array of S3 objects that were created.
5. On Invoke return on the Pi, read the return array
6. Download the processed images from S3.

That adds a good 4 steps to the process by calling a processor and separate storage area and will cause more moving parts that can fail, but without being able to run the processor natively, offloading to a separate server does seem to be the only way.

Now, here's the build process if anyone can see what's going on with it. I think that it's quite close to working but maybe missing a couple of minor tweaks to account for a different OS or some packages not be existing by default on the Pi.
I do have one last idea to try to compile this for an ARM.
Since there was no issues compiling this on Ubuntu but Debian wasn't as happy and the RasPi is a Debian build, I am trying to spin up an AWS EC2 Graviton c6g.xlarge Ubuntu instance to try the build process on.

@raspberrypi:~/Magick.Native/src/Magick.Native# sudo ../../build/linux/build.Native.sh
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /root/Magick.Native/src/Magick.Native/Q8
[ 2%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Colors/MagickColor.c.o
[ 4%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Colors/MagickColorCollection.c.o
[ 7%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Drawables/DrawingWand.c.o
[ 9%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Drawables/PointInfoCollection.c.o
[ 12%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Exceptions/MagickExceptionHelper.c.o
[ 14%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Formats/Pdf/PdfInfo.c.o
[ 17%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Helpers/Environment.c.o
[ 19%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Helpers/MagickMemory.c.o
[ 21%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Magick.c.o
[ 24%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/MagickFormatInfo.c.o
[ 26%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/MagickImage.c.o
[ 29%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/MagickImageCollection.c.o
[ 31%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Matricis/DoubleMatrix.c.o
[ 34%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/OpenCL/OpenCL.c.o
[ 36%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/OpenCL/OpenCLDevice.c.o
[ 39%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/OpenCL/OpenCLKernelProfileRecord.c.o
[ 41%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Optimizers/JpegOptimizer.c.o
[ 43%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Pixels/PixelCollection.c.o
[ 46%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Quantum.c.o
[ 48%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/ResourceLimits.c.o
[ 51%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Settings/DrawingSettings.c.o
[ 53%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Settings/MagickSettings.c.o
[ 56%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Settings/MontageSettings.c.o
[ 58%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Settings/QuantizeSettings.c.o
[ 60%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Statistics/ChannelMoments.c.o
[ 63%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Statistics/ChannelPerceptualHash.c.o
[ 65%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Statistics/ChannelStatistics.c.o
[ 68%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Statistics/Moments.c.o
[ 70%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Statistics/PerceptualHash.c.o
[ 73%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Statistics/Statistics.c.o
[ 75%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Stdafx.c.o
[ 78%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Types/ConnectedComponent.c.o
[ 80%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Types/MagickGeometry.c.o
[ 82%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Types/MagickRectangle.c.o
[ 85%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Types/OffsetInfo.c.o
[ 87%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Types/PointInfo.c.o
[ 90%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Types/PrimaryInfo.c.o
[ 92%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Types/StringInfo.c.o
[ 95%] Building C object CMakeFiles/Magick.Native-Q8-x64.dll.dir/Types/TypeMetric.c.o
[ 97%] Building CXX object CMakeFiles/Magick.Native-Q8-x64.dll.dir/foo.cxx.o
make[2]: *** No rule to make target '/usr/local/lib//libpangocairo-1.0.a', needed by 'libMagick.Native-Q8-x64.dll.so'. Stop.
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/Magick.Native-Q8-x64.dll.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

[brianpopow]

@barrct I had success compiling Magick.Native for ARM with this fork: https://github.com/Y56380X/Magick.Native.git
Note that some of the dependency's of Magick.Native are disabled. For example pango, lqr, glib and others.
Maybe looking at the commits of this forks will help you determining what you need to change in your build process.

Note for example the CROSS_COMPILE_FLAGS in the build scripts.

[barrct]

HA! Got it!
At least I think so.
I was trying different processes so I'm not 100% on the steps I took to get the binaries.
I'll have to replicate and verify.

I do know that it did compile natively on the RasPi though.
My team will test the rest of the code tomorrow.

[c-harris]

@barrct I am just working through the same process, did you have any luck replicating?

[kurattila]

@dlemstra @barrct Any news on Linux ARM builds?

[dlemstra]

Support for arm64 on Windows was recently added because it was easy to do a cross compilation with VisualStudio. Adding support for Linux ARM builds will probably not be added anytime soon.

[mikart143]

As .Net Maui became new standard for making apps in .net world, any chances to make this happen to run on arm ?

[dlemstra]

Good news support for Linux ARM64 was added. This will become available in the next release. This does not include support for jpeg-xl but support for this might be added in a future release.

[dlemstra]

Support for jpeg-xl in the Linux ARM64 build was added in the latest release.

[gswdn]

Nice, that ARM64 seems to be fully supported now. Good work!

As regular raspberry raspian is (still) 32 bit, any estimate, how far it is from ARM64 to ARM and if that is something going to be implemented as well?

[dlemstra]

I am not going to add 32 bit support for ARM.

[gswdn]

@dlemstra : Thank you for clarifying and letting us know. That really helps to plan my project. Hope, that 64bit raspian will become common soon.