libkrun: update to 1.16.0

[tsujp]

Description

I had previously removed the Makefile patch in favour of PREFIX on the build environment, but this results in an rpath for the library file that ignores the MacPorts prefix, e.g.

/opt/local/lib/libkrun-efi.1.15.1.dylib:
        /usr/local/lib/libkrun-efi.1.dylib (compatibility version 1.0.0, current version 1.15.0)
        /System/Library/Frameworks/Hypervisor.framework/Versions/A/Hypervisor (compatibility version 1.0.0, current version 210.6.2)
        /opt/local/lib/libepoxy.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libvirglrenderer.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
/opt/local/lib/libkrun-efi.1.dylib:
        /usr/local/lib/libkrun-efi.1.dylib (compatibility version 1.0.0, current version 1.15.0)
        /System/Library/Frameworks/Hypervisor.framework/Versions/A/Hypervisor (compatibility version 1.0.0, current version 210.6.2)
        /opt/local/lib/libepoxy.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libvirglrenderer.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
/opt/local/lib/libkrun-efi.dylib:
        /usr/local/lib/libkrun-efi.1.dylib (compatibility version 1.0.0, current version 1.15.0)
        /System/Library/Frameworks/Hypervisor.framework/Versions/A/Hypervisor (compatibility version 1.0.0, current version 210.6.2)
        /opt/local/lib/libepoxy.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libvirglrenderer.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

This updates libkrun to 0.15.1, re-introduces the Makefile patch (I feel it's simpler since the Makefile needs to be patched anyway) and also runs a check to ensure that the rpath is correct for the configured MacPorts prefix so this isn't missed again.

/opt/local/lib/libkrun-efi.1.15.1.dylib:
        /opt/local/lib/libkrun-efi.1.dylib (compatibility version 1.0.0, current version 1.15.0)
        /System/Library/Frameworks/Hypervisor.framework/Versions/A/Hypervisor (compatibility version 1.0.0, current version 210.6.2)
        /opt/local/lib/libepoxy.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libvirglrenderer.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
/opt/local/lib/libkrun-efi.1.dylib:
        /opt/local/lib/libkrun-efi.1.dylib (compatibility version 1.0.0, current version 1.15.0)
        /System/Library/Frameworks/Hypervisor.framework/Versions/A/Hypervisor (compatibility version 1.0.0, current version 210.6.2)
        /opt/local/lib/libepoxy.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libvirglrenderer.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
/opt/local/lib/libkrun-efi.dylib:
        /opt/local/lib/libkrun-efi.1.dylib (compatibility version 1.0.0, current version 1.15.0)
        /System/Library/Frameworks/Hypervisor.framework/Versions/A/Hypervisor (compatibility version 1.0.0, current version 210.6.2)
        /opt/local/lib/libepoxy.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libvirglrenderer.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

Type(s)

• enhancement

Tested on

macOS 15.6.1 24G90 arm64
Xcode 16.2 16C5032a

Verification

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tested basic functionality of all binary files?

[reneeotten]

please don't this doesn't need to be done on the buildbots or the end-users system. It's the responsibility of the maintainer to make sure everything is correct before pushing an update. Also, remove the check-rpath.sh file.

[reneeotten]

also, the conflicts should be resolved before this PR can be merged.

[tsujp]

This PR isn't final yet, I'm resolving another issue with EFI being deprecated. I asked jmr about adding this check in IRC and he said this would be the place to do it. Currently it's possible to install (as this port exists on MacPorts right now) and have a broken krunkit which cannot find libkrun as the rpath's don't use the MacPorts prefix. This script will make the port fail to install (a good thing) should a regression like this occur again.

[reneeotten]

I understand the purpose of the patch. But I don't agree it should be in the Portfile and/or run when the end-user is building the package (or when that happens on the buildbot). This is something you could/should run when you update the port and make sure everything works correctly before submitting a PR.

[tsujp]

Right but my concern is this specifically broke in an almost completely silent way beforehand. This is due to upstream's disagreeable Makefile requiring changes, and in the past on libkrun updates MacPorts correctly triggered ports like krunkit (which depend on this one) for rebuild. So on my last change to this port I assumed everything was fine, in-deed everything appeared fine. However, krunkit (right now) is actually broken due to the problem rpaths on this port libkrun.

Yes the ultimate error was mine with the PREFIX patch changes, but that's why I've added this check.

I can remember to run this script before each change to this port by keeping the script in the files folder and adding a note for others who might make a change to this port but surely it's better to rely on automation to ensure this doesn't break again as opposed to fickle human memory (which needs to be perfect, i.e. never forget to double check).

I should mention I also want to add a simple test upstream has in trying to use the library (to ensure it works) (see: https://github.com/slp/homebrew-krunkit/blob/main/Formula/libkrun-efi.rb#L26) and if this test that the rpath is set correctly is "out of scope" then wouldn't that upstream test, or any test for that matter, relating to a port functioning correctly also be out of scope?

If the logic was hugely complex then perhaps but this is simple and an easy safeguard for the future, or perhaps MacPorts should have a kind of --pedantic flag which if given runs a ports pedantic assertion tests so users etc can opt-in.

[neverpanic]

I think this is fine to have in the Portfile.

Similarly, we have a number of ports that use the gpg_verify PortGroup to verify an OpenPGP signatures over the downloaded artifacts, which is something maintainers could do, and yet it doesn't cost a lot of (CPU or wall clock) time, and it reduces the mental load on the maintainer.

In fact, this is very similar to what rev-upgrade already checks (except it ignores rpaths completely), and we also run that for every port, on every user system.

[neverpanic]

@tsujp Is this ready from your point of view now?

The current state of libkrun is bad, since it means krunkit will fail to run once it has been rebuilt (which for some reason happened today on my machine).

If this is in a mergeable state, I'd like to get it in to fix that problem. We can always iterate on improvements later.

Btw, rev-upgrade can detect the problem you're currently using the script for when called with --id-loadcmd-check:

Warning: ID load command in /opt/local/lib/libkrun-efi.1.15.1.dylib, arch arm64 refers to non-existent file /usr/local/lib/libkrun-efi.1.dylib
Warning: This is probably a bug in the libkrun port and might cause problems in libraries linking against this file

We just don't have this enabled by default, since it also checks for various other things, and this isn't an issue a rebuild typically fixes. This particular check was always better suited for a post-destroot phase check.

Now that we have the test phase always enabled, I should probably just move it there, ignore the cases we can't check due to variables, and make it fail when it detects a clear-cut case such as yours. Until that happens, your script is still the best option, though.

[tsujp]

@neverpanic this PR should be good if the script workaround is acceptable for now.

librkun as built with this PR won't be borked for krunkit like it currently is from the previous PREFIX simplification attempt.

The krunkit rebuild happens because MacPorts sees the linking has been botched, but the link-botching is on libkrun so rebuilding krunkit does nothing unless libkrun is also rebuilt (with fixed linking as in this PR). Hence the script to prevent this nasty interaction from slipping through my fingers again.

[tsujp]

Also I believe it's not strictly the rpath that's the problem here since that's @rpath but rather what... the linked-library-location-paths or whatever? As we know naming things is the hardest problem in computer science.

[neverpanic]

OK, I'm merging this in order to fix the krunkit breakage.