libpng-1.2.12

[Randy McMurchy]

Version increment to 1.2.12

​http://sourceforge.net/projects/libpng

[Randy McMurchy]

I played around a bit with this new release of libpng. It has an autotooled build system now, but I suppose we shouldn't use it. Even though the INSTALL file says to CMMI, the KNOWNBUG file identifies (rightly) that the library name doesn't represent the version correctly and that system library builders should use the custom makefile method used in past versions.

I feel it would be trivial to use the autotools installation and create properly versioned library names and symlinks, however, that probably isn't the 'right' thing to do. Unfortunately, the custom makefiles have been modified and the patch no longer applies and zlib and libm do not get pulled in properly. This is a trivial fix as well.

I'm going to play around a bit more and see how much hacking is required in Makefile.am to use the autotools and come out with a library named libpng12.so.0.1.2.9. Right now libtool is creating a library named libpng12.so.0.9.0, which probably would be fine as the symlinks libpng12.so and libpng12.so.0 would still link to all the packages looking for libpng.

[dnicholson@…]

That's nice the libpng is now using autotools. On the zlib-devel list, the maintainer is considering moving to autotools, but there are some dissenters.

Anyway, it doesn't seem worth it to change the library version in my opinion. As long as the API hasn't changed, then the symlinks will pull in the correct library during building and older binaries will still find a compatible libpng12.so.0. I think we should just go forward with the new versioning via libtool. Changing the version number now would just delay the inevitable.

[Randy McMurchy]

I agree completely, Dan. However, should we just wait until 1.3.0? The Makefiles and other docs say that major versioning will take place in the 1.3.0 release. Everything will be probably straight CMMI then. And it could be now as well, as long as we are content with

libpng12.so.0.9.0 libpng12.so.0 libpng12.so libpng12.la libpng12.a libpng.so.3.9.0 libpng.so.3 libpng.so libpng.la libpng.a

Probably time to move this discussion to -dev. I'll summarize our comments and post it up.

[Randy McMurchy]

Downgrading this bug to after 6.2. It gains us nothing to update this package in 6.2 other than headache. There are ABI/API compatibility issues where patches are already necessary. Simply not worth the update for the risk involved.

[Randy McMurchy]

Version increment to 1.2.10

[Randy McMurchy]

I used this version at the beginning of a BLFS build on top of the current LFS SVN and so far everything is working as expected. There was a report that the 1.2.9 version had an issue with the Gimp, but I've not installed it yet, so I cannot say.

[Randy McMurchy]

Indeed, there is an issue with the Gimp, who initially blamed the libpng author for breaking the API. But as it turns out, the Gimp has had code that libpng deprecated 4 years ago, and Gimp CVS is already fixed.

Either way, the fix is trivial, and I'm sending in a patch. So far, this is the only thing I can tell that this new version of libpng affects.

I'll continue testing more packages, but so far I am leaning to jumping the fence on this issue, and saying this version would be fine for 6.2

Not sure what is gained though, with this version.

[Randy McMurchy]

Version increment to 1.2.12

[Randy McMurchy]

Now that 3 months have elapsed since the first update to libpng, and I've tested every package I can think of against the new libpng with good results, I can see no reason not to go ahead and update to the latest version for BLFS-6.2.

[Randy McMurchy]

Updated BLFS to libpng-1.2.12

I have been using it for a long time, and I cannot find one BLFS package that is incompatible with it. I can see no reason any longer to stay at 1.2.8.