mupdf: actually build and install the shared libraries version

[delroth]

Description of changes

The current version of the derivation builds in shared libraries mode, but then the "shared" flag is not passed to the "make install" invocation. This causes "make install" to perform a whole second build from scratch, in static mode, and install this to $out instead.

Instead pass shared=yes as part of the makeFlags -- this is basically the only thing that the "shared" build target does anyway, and I don't think there is a similar target for "make install".

This issue was detected because the .pc shipped with mupdf doesn't work with the static libraries currently shipped (it doesn't include recursive dependencies like zlib).

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[delroth]

Incidental closure size savings:

$ du -sh /nix/store/81gp3akl0h55r9fs62jvnnbaim1rz8r7-mupdf-1.22.1-bin
175M    /nix/store/81gp3akl0h55r9fs62jvnnbaim1rz8r7-mupdf-1.22.1-bin

$ du -sh /nix/store/r45wsh1i07cwqha28nhd70vdd1m1bind-mupdf-1.22.1-bin
848K    /nix/store/r45wsh1i07cwqha28nhd70vdd1m1bind-mupdf-1.22.1-bin

[Mindavi]

I wonder how all those dependents consume mupdf if it was broken...

[delroth]

I wonder how all those dependents consume mupdf if it was broken...

The answer to that seems to be "via a dependency on cups-filters, which depends on the binaries only": --with-mutool-path=${mupdf}/bin/mutool.

The good news is that this means this PR should translate to a pretty nice closure size decrease on cups itself.

[delroth]

Before: /nix/store/1f0r6gh1jncp9iv49qmiybsx8n0rjfxa-cups-filters-1.28.17 464.8M
After: /nix/store/mxkg4yhg7fwar14vz6q56w9fvbb3hbhw-cups-filters-1.28.17 337.2M

[delroth]

And for completion's sake, I built the commit from Oct 2020 which removed the previously used custom patch for shared libraries building (e13120b):

$ nix build 'github:nixos/nixpkgs?rev=e13120bb098f25ac552570c2f9ea5908ef102a50#mupdf'
$ ls result-bin/bin -lah
-r-xr-xr-x 2 root root  35M Jan  1  1970 mupdf-gl
-r-xr-xr-x 2 root root  34M Jan  1  1970 mupdf-x11
-r-xr-xr-x 2 root root  34M Jan  1  1970 mupdf-x11-curl
-r-xr-xr-x 2 root root  34M Jan  1  1970 muraster
-r-xr-xr-x 2 root root  35M Jan  1  1970 mutool

So when dropping the custom patch and trying to use upstream's mechanism to use shared libraries, a regression was introduced and never noticed until now... :(

[delroth]

Actually nevermind, it was noticed (see the last few comments on the PR), but fixed by adding the transitive dependencies to downstream packages, which was the wrong fix. Ugh.

#103727 & #103723

[github-actions]

Successfully created backport PR for staging-23.05:

• [Backport staging-23.05] mupdf: actually build and install the shared libraries version #237337

[vcunat]

Backporting already? I see regressions on Hydra:

• https://hydra.nixos.org/build/225315851/nixlog/2/tail
• https://hydra.nixos.org/build/225239845/nixlog/2/tail
• https://hydra.nixos.org/build/225252783/nixlog/8/tail
• https://hydra.nixos.org/build/225272946/nixlog/2/tail

[delroth]

Feel free to revert this commit, I didn't realize that so many people had written workarounds around what is an obvious bug in the derivation (it was literally unusable unless you went and duplicated all its build inputs into your own build inputs). Frankly I don't have that much motivation to clean up other people's mess. Thanks for tracking down these Hydra failures.

If it had taken less than 2 weeks for a breakage to get noticed perhaps I'd still have some interest in fixing this, but I'm not about to dive back into this now.

[lilyinstarlight]

Second attempt at this PR is in #261113 (with all reverse regressions that I could (on aarch64-linux) find fixed)