@korimitsu this is a problem with upstream libultrahdr, and not with ImageMagick, and neither a packaging issue. I have pushed a fix for libultrahdr-git, and now the package is building fine when using it.

Fails to build:

  CCLD     coders/tiff.la
  CC       coders/uhdr_la-uhdr.lo
In file included from coders/uhdr.c:47:
/usr/include/ultrahdr_api.h:320:72: error: unknown type name 'bool'
  320 |                                                                        bool use_multi_channel_gainmap);
      |                                                                        ^~~~
/usr/include/ultrahdr_api.h:1:1: note: 'bool' is defined in header '<stdbool.h>'; this is probably fixable by adding '#include <stdbool.h>'
  +++ |+#include <stdbool.h>
    1 | /*
make[1]: *** [Makefile:11408: coders/uhdr_la-uhdr.lo] Error 1
make[1]: Leaving directory '/home/user/.cache/paru/clone/imagemagick-full/src/ImageMagick-7.1.1-33'
make: *** [Makefile:6259: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
error: failed to build 'imagemagick-full-7.1.1.33-1': 
error: packages failed to build: imagemagick-full-7.1.1.33-1

@Nact @jpgeee @korimitsu try to build using pstoedit-nomagick and autotrace-nomagick. Also, make sure that your magickcache-git is linked against imagemagick-full, and not against the repository imagemagick (you need to build it two times, due to the circular dependency).

Fails to build:

In file included from /usr/include/librsvg-2.0/librsvg/rsvg.h:1458:
/usr/include/librsvg-2.0/librsvg/rsvg-cairo.h:90:10: note: declared here
   90 | gboolean rsvg_handle_render_cairo (RsvgHandle *handle, cairo_t *cr);
      |          ^~~~~~~~~~~~~~~~~~~~~~~~
  CCLD     coders/svg.la
/usr/bin/ld: cannot find -lMagickCore-7.Q16HDRI: No such file or directory
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:7868: coders/svg.la] Error 1
make[1]: Leaving directory '/home/sam/.cache/paru/clone/imagemagick-full/src/ImageMagick-7.1.1-32'
make: *** [Makefile:6264: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
error: failed to build 'imagemagick-full-7.1.1.32-1': 
error: packages failed to build: imagemagick-full-7.1.1.32-1

ok
PASS: Magick++/tests/tests.tap 1
Testing throwing and catching exceptions. A program crash or a message
that the exception was not caught indicates a test failure.  A properly
formatted exception message indicates success:
Caught exception, good!:
  "attributes: unable to open image 'foo': No such file or directory @ error/blob.c/OpenBlob/3571"
ok
PASS: Magick++/tests/tests.tap 2
ok
PASS: Magick++/tests/tests.tap 3
ok
PASS: Magick++/tests/tests.tap 4
Caught exception: coderInfo: unable to load module '/home/..../imagemagick-full/src/ImageMagick-7.1.1-31/coders/svg.la': file not found @ error/module.c/OpenModule/1293
not ok
FAIL: Magick++/tests/tests.tap 5

Anyone running into this?

@frankspace using symlinks for different libraries is not a good practice and should be avoided. This can lead to unpredictable results and crashes.

@dreieck regarding libumem, it does not make any difference, as there is no stable libumem package, and probably there will not be, as upstream libumem is abandoned and very old. Also, libumem builds in linux only with some unsupported patches, and I cannot remember if they apply to the old tagged version (probably not, as patches are based on git master). Removing imagemagick from provides is technically correct, but that's not so simple in this case. This package must conflict with imagemagick, and being such, any package that depends on imagemagick will not be able to use this one if it would not provide imagemagick. As far as I understand, making it to install alongside with repository imagemagick is not trivially possible, as the configuration files in '/etc' will conflict, and I'm not aware of a supported upstream way to specify a different directory for these files. A good reasonable solution is to make it provide imagemagick and let the user build/rebuild target packages against it, although being technically incorrect since it does not provide the same Q16 libraries.

@dreieck and @dbermond, this is probably a very stupid question, but regarding 32-bit/16-bit compatibility, is there any particular reason why the distinction would actually break anything if you just added some symlinks? For example, ln -s /usr/lib/libMagickCore-7.Q32HDRI.so ${pkgdir}/usr/lib/libMagickCore-7.Q16HDRI.so and so on? That's literally what the official libudev0-shim package does, after all. And maybe it would break; I genuinely don't know. (This has nothing to do with the libumem or magickcache stuff, just the bit depth stuff.) If shimming wouldn't break anything, that'd seem to solve that particular problem, wouldn't it?

There is no libumem and magickcache stable packages, so the only option is depending on libumem-git and magickcache-git.

The conclusion is wrong. libumem-git provides libumem, magickcache-git provides magickcache. So the -git packages wills suffice to satisfy the dependencies.

If there would be a magickcache stable package, it currently needs code that is only in the magickcache git master branch, and will not compile with the old magickcache release from 2022

That is a valid argument to use magickcache-git over magickcache.
Does the same hold true for libumem-git?

Being a -full package, it uses 32-bit depth by design and does not provide 16-bit depth, so you need to recompile anything that needs the 16-bit depth libraries

Then you must remove the imagemagick and libmagick provides entries, since it is not a drop-in replacement for Arch Linux' imagemagick: Other Arch Linux repo software will not work.

You then should adapt the package that it can be installed in parallel with the stock imagemagick.

E.g. rename it to "imagemagick-32bit-full" or something similar.

Regards and thanks for the package!