As I quickly noted yesterday I started testing libpng-1.5 in the tinderbox to identify the packages failing to build with the new version. As it turns out there are quite a few as usual.
The problem turns out to be more complex than I’d have expected, though. My first step after installing the new libpng version was to make sure that no dangling package was present in the system, by running revdep-rebuild -- -C which supposedly should have removed all the libpng-using packages. I’ll be honest and say here that I was way too naïve and I shouldn’t have done so as first step at all.
While revdep-rebuild identified all the packages that installed .la files referencing libpng, which are quite a lot more than they should be, as I noted in the above-linked post, it didn’t seem to identify the broken ELF linking at all. I’m not sure why that is, maybe revdep-rebuild in the tinderbox is broken, or some package installs a wrong mask entry, but no matter what’s the case, I ended up having all the packages without .la files but with ELF linking to libpng14.so.14 still installed.
Thankfully, I whipped up quickly a scanelf/@qfile@ pipeline that provided me with a list of linked packages, which I could then remove and … compare with the reverse dependencies as produced by the QA Reports — turns out that there are packages linking to libpng (actually using it) and not listing it as a dependency. Reminds me of transitive dependencies that I discussed… over an year ago.
Unfortunately, it also appears to be a problem for the upstream code. One of the common failure has to do with zlib.h not being included by png.h any longer, which is a positive thing (as it stops entangling two libraries’ headers), but there are at least a few packages that used zlib’s interfaces without including zlib.h themselves. Again, isn’t it lovely, how people pretend not to include the headers they import functions and constants from? Unfortunately, while this is easy to notice for packages using constants such as Z_BEST_COMPRESSION, it might leave the compiler with just an implicit declaration (which might be further problem on 64-bit systems) if functions are involved.
And this is not all, of course. Even though I’m doing my best at covering as many packages as possible in the tinderbox, the guest I’m using for the builds right now is far from having a 100% coverage. The main issue is that it’s still testing glibc-2.14 — and I’m still finding packages that try to use RPC code and fail, I wouldn’t have guessed so many packages used it. And that also means I’m lacking Ruby altogether, as it fails badly during its own bootstrap, which in turn means that there are my own packages that I can’t test properly right now. I guess the second round of libpng-1.5 testing will happen in the 64-bit tinderbox that is still running glibc-2.13.
Back to work, I guess.