Install doxygen - this installs graphviz, which requires libpng=1.0, and so installs libpng-1.0*, which trashes the libpng-1.2* versions of png.h and pngconf.h. Update qt. This compiles against the 1.0 headers, but links against the 1.2 libpng.so (probably because it uses libpng-config to determine what is installed, and this only exists with libpng-1.2...). Restart KDE and all the .png files fail to load, including all those that appear on the panel and desktop. It also appears to kill kcontrol, which doesn't cope well when it can't load its eye-candy. I'd suggest that graphviz should carry its own version of libpng and link it statically, but a bigger issue is that libpng-1.0 and libpng-1.2 are mutually exclusive - you can't have both fully installed safely (in their current form, anyway).
I'd say it doesn't use libpng-config because if it did shouldn't it select the appropriate headers in /usr/include/libpng12 ? Thats the path libpng-config --I_opts return on my system. Why is libpng and libpng 1.2 mutually exclusive ?
Hmm, interesting point. And, now that I've had a look at the CONTENTS files, the answer is rather annoying. libpng-1.0.12-r1/CONTENTS: dir /usr dir /usr/include obj /usr/include/png.h c44f187d27ae1d03e3b7d37b93e1ec8f 1039186969 obj /usr/include/pngconf.h 134cf56e08d03fcd0591019661f2561a 1039186969 dir /usr/lib obj /usr/lib/libpng.a 8b52583d78468d4ffa799b6cd08440f7 1039186969 obj /usr/lib/libpng.so.2.1.0.12 b6a37a07ea342f1ca8f85f59c07b7cdc 1039186969 sym /usr/lib/libpng.so.2 -> libpng.so.2.1.0.12 1039186969 sym /usr/lib/libpng.so -> libpng.so.2 1039186969 ... libpng-1.2.12-r1/CONTENTS: dir /usr dir /usr/include dir /usr/include/libpng12 obj /usr/include/libpng12/png.h d9810e926cf02e0ecc1967edcedb5c0c 1040292435 obj /usr/include/libpng12/pngconf.h 6262671479b2c2d372a1ca084df6a745 1040292435 sym /usr/include/libpng -> libpng12 1040292435 sym /usr/include/png.h -> libpng12/png.h 1040292435 sym /usr/include/pngconf.h -> libpng12/pngconf.h 1040292435 dir /usr/lib obj /usr/lib/libpng12.a e45fcfd0a83e181ce2e3c8f85869c90a 1040292435 sym /usr/lib/libpng.a -> libpng12.a 1040292435 obj /usr/lib/libpng12.so.0.1.2.5 9f587455fc077a2bb161483278b219e8 1040292435 obj /usr/lib/libpng.so.3.1.2.5 52d46548635b8e8b469ae805f5d85ecc 1040292435 sym /usr/lib/libpng.so.3 -> libpng.so.3.1.2.5 1040292435 sym /usr/lib/libpng.so -> libpng.so.3 1040292435 sym /usr/lib/libpng12.so.0 -> libpng12.so.0.1.2.5 1040292435 sym /usr/lib/libpng12.so -> libpng12.so.0 1040292435 dir /usr/lib/pkgconfig obj /usr/lib/pkgconfig/libpng12.pc 97bfd00febd545bcfa26f897c14cdf71 1040292435 sym /usr/lib/pkgconfig/libpng.pc -> libpng12.pc 1040292436 ... dir /usr/bin obj /usr/bin/libpng12-config f3a2f69422941836a773985afe4ddab3 1040292435 sym /usr/bin/libpng-config -> libpng12-config 1040292436 As you can see, libpng-1.2 installs nice symlinks from /usr/include/png.h to /usr/include/libpng12/png.h. It's a shame that the installation of libpng-1.0 (a) doesn't install its headers into libpng-10; (b) the installation process for libpng-1.0 installs to /usr/include/png.h, but this happily follows the symlink and clobbers the /usr/include/libpng12/png.h file. I've had a quick look through portage.py and as far as I can tell, if a new emerge is going to overwrite a symlink with a regular file, the symlink is *not* removed, and hence the copy of the regular file will follow the symlink, trashing what it points at. (This is sensible behaviour for directories, but is rather more arguable for regular files - in the case of libpng, it is just plain wrong.)
I'm creating something experimental here -- a png-config type utility to allow switching on the fly (and creating symlinks on the fly). Gimme a few hours and I'll have something for y'all to test.
Hmm, looking at the makefile.linux for libpng it should feasible to move the include files into /usr/include/libpng-10. But i'm afraid it might create more problems than it solves unless autoconf for KDE is updated at the same time.
I added libpng-1.0.15 which really should sort this.
Doesn't solve it for me. I emerge -C libpng and then no matter the order i merge 1.2.5 and 1.0.15, i still cant compile libdvbpsi because the dot program from graphviz fails with: make -C doc doc make[1]: Entering directory `/var/tmp/portage/libdvbpsi-0.1.2/work/libdvbpsi-0.1.2/doc' dot -Tpng -o decoder.png decoder.dot libpng warning: Application was compiled with png.h from libpng-1.0.15 libpng warning: Application is running with png.c from libpng-1.2.5 gd-png: fatal libpng error: Incompatible libpng version in application and library make[1]: *** [decoder.png] Segmentation fault make[1]: *** Deleting file `decoder.png' make[1]: Leaving directory `/var/tmp/portage/libdvbpsi-0.1.2/work/libdvbpsi-0.1.2/doc' make: *** [doc] Error 2
Hi, i updated graphviz to 1.8.10-r2 (which depends on libpng-1.0.15) and get the following error during emerge kdelibs-apidocs: Error: Problems running dot. Check your installation! libpng warning: Application was compiled with png.h from libpng-1.0.15 libpng warning: Application is running with png.c from libpng-1.2.5 gd-png: fatal libpng error: Incompatible libpng version in application and library /usr/lib/graphviz/libgd.so is linked against /usr/lib/libpng.so.3 (which is provided by libpng-1.2.5-r3.ebuild.
Hi guys. Thanks for testing! Well, that was kind of strange, since I did not seem to experience this problem with the -r2. Anyway, I updated the graphviz ebuild to change all end every instance of -lpng to -lpng10 in all scripts and Makefiles. Should now link correctly everywhere. I revision bumped graphviz-1.8.10 again, since the failure might not have been very apparent and some people might be silently affected. Please test. Also, prior to remergind graphviz, colud you guys please completely unmerge all instances of libpng and then emerge 1.0.15 and 1.2.5-r2? I am worrying that you might have been bitten by the stale png.h from libpng-1.0.12: libpng-1.0.15 was finally mangled to get rid of all files in common with 1.2.x series, so the order in which you emerge these versions should not matter now. Still this means that /usr/lib/png.h no loner belongs to libpng-1.0.15 and thus you might have had stale png.h from libpng-1.0.12 if you did not remerge 1.2.x after it. I revision bumped 1.2.5 when 1.0.15 was released in order to eliminate possiboility of this, however you might have been caught by the update (well, clean system should have benn updated correctly, but as usually recovering messy one can be a bit more tricky). I'll RESOLVE/Test-request this bug for now. Please reopen it if the problem is still not solved. Otherwise please let me know of success, so that I could mark graphviz-1.8.10-r3 stable and remove all prior 1.8.x revisions. George
George: thx again. works fine here :)
db fix
