>
>>         (modules '((guix build utils)
>>                    (ice-9 ftw)
>>                    (srfi srfi-1)))
>> @@ -895,6 +895,7 @@ (define-public mupdf
>>             libx11
>>             libxext
>>             mujs
>> +	   brotli
>
> Is this strictly needed for the update?  Otherwise, it'd be best done in
> a distinct, separated commit.

Indeed, it is a new dependency with the update.
>
>>             openjpeg
>>             openssl
>>             zlib))
>> @@ -907,6 +908,7 @@ (define-public mupdf
>>        #~(list "verbose=yes"
>>                (string-append "CC=" #$(cc-for-target))
>>                "XCFLAGS=-fpic"
>> +	      "USE_SYSTEM_BROTLI=yes"
>
> I assume that's necessary and not something the build system
> automatically tries?  If the later, do not explicit it (it makes inputs
> rewriting less useful).

Indeed, the build system doesn’t do that with USE_SYSTEM_LIBS=yes.

>>                "USE_SYSTEM_FREETYPE=yes"
>>                "USE_SYSTEM_GUMBO=yes"
>>                "USE_SYSTEM_HARFBUZZ=yes"
>> @@ -921,7 +923,7 @@ (define-public mupdf
>>                "USE_SYSTEM_CURL=yes"
>>                "USE_SYSTEM_LEPTONICA=yes"
>>                "USE_SYSTEM_TESSERACT=yes"
>> -              "USE_SONAME=no"           ;install as libmupdf.so
>> +              "USE_SONAME=yes"
>

Without enabling that, one runs in to "Too many levels of symbolic links" errors. This is due to a recent change in mupdf upstream that updated their symbol table for the library. I was part of the changes made for this, and the devs agree that USE_SONAME should be enabled. Here’s the backtrace with USE_SONAME=yes:

error: in phase 'validate-runpath': uncaught exception:
system-error "open-file" "~A: ~S" ("Too many levels of symbolic links" "/gnu/store/j6r6rgvmmm59a8i7vh330c7bpxmgicma-mupdf-1.26.0/lib/libmupdf.so") (40) 
phase `validate-runpath' failed after 0.0 seconds
Backtrace:
          13 (primitive-load "/gnu/store/304wldk8xn5xd2cnpvr66lbkn82…")
In guix/build/gnu-build-system.scm:
    966:2 12 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
    634:9 10 (for-each #<procedure 7fffef021240 at guix/build/gnu-b…> …)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   987:23  8 (_)
   605:16  7 (validate-runpath #:validate-runpath? _ # _ #:outputs _)
In guix/build/utils.scm:
   735:23  6 (loop ("/gnu/store/j6r6rgvmmm59a8i7vh330c7bpxmgicma…" …) …)
In guix/build/gnu-build-system.scm:
   587:36  5 (validate "/gnu/store/j6r6rgvmmm59a8i7vh330c7bpxmgicma-…")
In guix/build/utils.scm:
   549:10  4 (find-files "/gnu/store/j6r6rgvmmm59a8i7vh330c7bpxmgic…" …)
In ice-9/ftw.scm:
   505:39  3 (loop _ _ #(25 88653728 16877 1 999 30000 0 22 # # # …) …)
In guix/build/utils.scm:
   551:34  2 (_ "/gnu/store/j6r6rgvmmm59a8i7vh330c7bpxmgicma-mupdf-…" …)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure open-file: Too many levels of symbolic links: "/gnu/store/j6r6rgvmmm59a8i7vh330c7bpxmgicma-mupdf-1.26.0/lib/libmupdf.so"
build process 18 exited with status 256


Also, I don’t want to open another bug report, but enabling SONAME breaks sioyek which depends on mupdf-1.24. Since the latter inherits from mupdf, thus also inheriting USE_SONAME=yes, it breaks sioyek that relies on having it disabled.

I’ve attached another patch that specifically disables SONAME for mupdf-1.24, allowing sioyek to build fine as usual.