Yeah, we need to do some updating. libxml needs to go to v2.7.x at some stage too etc.

Note that libpng 1.2.42 was released on Jan 3 2010, so this isn't too urgent yet.

You will face the same issue that you face with libjpeg.so.62 vs libjpeg.so.7. 
Chromium (the browser) compiles fine against libpng 1.4.0 once the use of the png 
NULL macros has been fixed (see attached patch), however libpng12.so.12 and 
libpng14.so.14 can be installed in parallel and are *not* ABI compatible.  (No 
surprise there I hope.)

This really is a system builder issue - if someone is building systems and 
distributing binaries it is up to the distributor to ensure everything gets built 
against the same core libraries or that the core libraries have symbol versioning.  
(Symbol versioning allows you to use two different ABI versions in the same program.)

Including your own copies of the libraries is not just distributing bloatware; it 
forces you to track all the security issues and re-issue both binary and source PDQ 
when an issue is discovered.  You will probably find that you end up loading the 
shared library too anyway: last time I tried I could not persuade ld.so to link back 
against symbols in the main program without major work.

BTW libpng1.2 is fully supported - it gets any security fixes.  The main point of 
1.4 is to allow changes that can't be made without an ABI change, in particular the 
use of non-Western European text in the values of keyword comments.

chromium-4.0.251.0-libpng-1.4.patch 2.0 KB View Download

Thanks for the note.  If libpng1.2 is fully supported, then I'm inclined to close this 
bug until we see a need to use 1.4.

You (chromium guys) don't get any choice.  If a system builder choses to upgrade the 
core libpng to 1.4 - likely for anyone building systems for use outside the 
parochial confines of the US because of the i18n support - then all apps will be 
built against it.

Since the API changes are minimal, as as with the JPEG-6b -> JPEG-7 transition, 
system builders are likely to do this.  The only way you can avoid this is to 
statically link, which actually creates more problems than it solves in maintenance 
terms.

All you need to do is to patch the NULL macros then everything works regardless of 
which library chromium gets built against.  (In other words Chromium doesn't seem to 
have any significant API dependencies on libpng 1.2.)

Of course you still need to solve the problem of distributing binaries built against 
the wrong ABI, but that's a much bigger problem and one that requires solutions from 
the system builders.

That makes sense.  Since part of your patch is a patch to webkit, would you mind 
creating a bug and uploading it to the webkit bug tracker?  bugs.webkit.org

(Don't worry about all their process, like creating a changelog; I would just like to 
not lose the patch)

It's not a problem in the WebKit stable build (1.1.15.4); the code in question was 
added by Google (to WebkitGTK, dglazkov@chromium.org) solely to support Chromium 
tests, I can see it on the web and it seems to have been patched in on 2009-Feb-05.

Anyway, it's:

https://bugs.webkit.org/show_bug.cgi?id=33287

 Issue 34415  has been merged into this issue.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.