Created attachment 247532 [details] Upgrade graphics/libmng to 2.0.3 Despite the seemingly large version-jump, the sole change in the upstream's code is the compatibility with lcms-2.x The proposed upgrade would make use of that -- and close some ancient bugs in the upstream's code. Because there are neither ABI nor API changes, I'm not even changing the shared library version, which should spare some commotion among the depending ports. However, because of the switch from lcms-1.x to lcms-2.x, an exp-run may be warranted...
I actually hacked on this earlier today and here's a CMake variant with your patches included. https://projects.pyret.net/files/freebsd-patches/libmng203v2.patch Less patching and cleans up the Makefile somewhat too. Compiles fine on 13.2-RELEASE (amd64) with following consumers: devel/love07 games/stratagus graphics/devil graphics/gimageview graphics/gimp-app graphics/qt5-imageformats graphics/qt6-imageformats graphics/synfig misc/magicpoint multimedia/libxine sysutils/graveman I dont think we should enable the by default disabled optimization given it only seems to save a few kilobytes and no other distro seems to enable it either but that's up to you. Best regards, Daniel
> a CMake variant with your patches included But that introduces a (large) build-time dependency :/ > by default disabled optimization Sorry, I don't understand. The optimization is now _always_ on -- unconditionally. At least, that's my intention :) Could you confirm?
All listed consumers and very likely ones where libmng is optional either depends on CMake or have dependencies which will pull in CMake so I'd argue that it doesn't matter looking at the bigger picture. The Makefile variant also seems to drop flags (unintentionally) during linking As for the optmization it's probably better to leave it off as it's disabled by default and seems to be intended to save a few kbytes of diskspace according to the documentation. For the sake of consistency, all distro's I've looked have followed upstream in that regard. I can confirm that the optimization on the Makefile variant is unconditionally enabled.
> The Makefile variant also seems to drop flags (unintentionally) during linking Uhm?.. Anything significant dropped? As for optimization, that's how I always built it myself here. It does produce smaller binaries (total package goes from 1.2Mb to 1.3Mb with optimizations disabled), whatever that's worth. > I can confirm that the optimization on the Makefile variant is unconditionally enabled. Thank you! I'll sit on it a little longer before committing...
-fpic -DPIC -O2 -pipe -march=tigerlake (last one is CPUFLAGS) gets dropped
(In reply to Daniel Engberg from comment #5) > -fpic -DPIC -O2 -pipe -march=tigerlake (last one is CPUFLAGS) gets dropped But those are only relevant to the compiler -- not linker. That's why <bsd.lib.mk> does not include them for the entire src/ tree (and the few ports, that use it).