kde3.1rc3 kdelibs compilation fails, tail of the compilation attached. Is this related to [9702] (which I was affected by as well)? I note the comments there about libpng 1.0 and 1.2. libpng error: Incompatible libpng version in application and library libpng warning: Application was compiled with png.h from libpng-1.2.5 libpng warning: Application is running with png.c from libpng-1.0.12 libpng error: Incompatible libpng version in application and library libpng warning: Application was compiled with png.h from libpng-1.2.5 libpng warning: Application is running with png.c from libpng-1.0.12 libpng error: Incompatible libpng version in application and library libpng warning: Application was compiled with png.h from libpng-1.2.5 libpng warning: Application is running with png.c from libpng-1.0.12 libpng error: Incompatible libpng version in application and library make[4]: *** [cr22-action-kde.png] Floating point exception make[4]: Leaving directory `/var/tmp/portage/kdelibs-3.1_rc3/work/kdelibs-3.0.99/pics/crystalsvg/kde' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/kdelibs-3.1_rc3/work/kdelibs-3.0.99/pics/crystalsvg' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/kdelibs-3.1_rc3/work/kdelibs-3.0.99/pics' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/kdelibs-3.1_rc3/work/kdelibs-3.0.99' make: *** [all] Error 2
it looks like you installed the old libpng over the new one. please emerge libpng again, and you should be set
thanks, that fixed it. I hadn't previously explicitly emerged libpng ever, though.
I ran into this as well. I had something that needed libpng 1.0.x specifically -- portage allows you to install both 1.2.x and 1.0.x concurrently, but it ends up screwing with some KDE applications that are built after you do that. Then if you remove 1.0.x you have to both rebuild libpng 1.2.x and rebuild any applications that were merged after you had both versions of libpng installed. I'm not 100% sure about this, but it might be a good idea to prevent two versions of libpng from being installed.
actually its a good idea to wipe libpng-1.0.x from the tree and kill all programs that depend on it. afaik -nothing- that doesn't want to exlicitly break every other package installed should want to use that, or at least not unless it isn't dependant on any other lib... QT apps can fex. not use libpng 1.0.x since QT links 1.2.x, that makes opera's dep on libpng 1.0.x bogus, as it still wont work due to libpng collisions... unless QT and all QT dependant packages are also rebuild with the old libpng headers. making libpng 1.2.x block 1.0.x would work now, as we no longer have "mix case installs"
OK, do you want to handle that? :-)
...or toss it to bug-wranglers I suppose.
aagh, cant make libpng block libpng, since portage can't support that. jolly great.
shall we just erase it?
Don't ask me, I have no opinion of my own. That is, I've no objections to removing libpng 1.0.x :-)
well, the only package left which "needs" libpng is graphviz, we should try to have it using libpng-1.2.x?
added george in cc, because he submitted graphviz-1.8.10.ebuild (which is the only package which depends on libpng-1.0.x) see bug #9702 for more details about the graphviz thing graphviz compiles here fine with libpng-1.2.4. can someone please check this and if this works, we should remove libpng-1.0.x (and graphviz should not depend on =libpng-1.0*)
Hi guys. Sorry to bring the bad news, but graphviz *will not* compile against libpng-1.2.x. At least not allways. In fact I had to make dependency on libpng stricter after getting a few bug reports saying that graphviz build breaks complaining about libpng and reading in the README (or may be somewhere else in the docs) that libpng-1.0.x was on the list of required things. Now, to me this only means that graphviz authors built it against libpng-1.0.x, not that it should abolutely not work 1.2 series. Unfortunately looks like some people (myself included) had problems with such a setup. But then, earlier on, I was able to build it agains some 1.2 version of libpng. So, in short, sometimes you will get lucky, but it is *not guaranteed* to work with 1.2. (Please take a look at #11481 for example, there was one more bug that is closed now). Now a bit on libpng itself: Just few days ago I got a bug where user complained about graphviz build failing. It turned out that even though he had both versions of libpng installed, the 1.2 version was somehow "taking over". He cured his situation by emerging the 1.0 and then graphviz. This bug lists just the opposite occurences - where it was necessary to emerge 1.2 on top of 1.0. Now, libpng is SLOTted as I can see, however still it seems that the two versions somehow overlap, which as I understand is inappropriate situation for the slotted libraries. From this thread I got an impression that this problem is not easily cured, and the easiest solution is to abandon the 1.0 series. Unfortunately, graphviz-1.8.10 is the latest version and it does not seem to like 1.2 very much. Thus I do not see an easy way to drop libpng-1.0 other than by masking graphviz, however this will also cause some trouble, as some packages depend on it (e.g. doxygen, see #10812). Doing some more digging... Well, it might look like it may be possible :), to build graphviz without libpng support. I'll try to check that and report here. If that fails, I am not sure of the best course of action. George
thanks for your long comment, george. is the error always the same (the one in bug #11481)? are there any connections to the authors of graphviz (maybe they want to help us to have graphviz build against newer libpng)? according to http://packages.debian.org/unstable/graphics/graphviz.html debian uses graphviz with libpng3 (which is libpng-1.2.5 according to http://packages.debian.org/unstable/libs/libpng3.html). maybe we can borrow us their patch (http://ftp.debian.org/debian/pool/non-free/g/graphviz/graphviz_1.8.9-1.diff.gz)? well, i don't know much about graphviz, and it compiles here with libpng-1.2.4... otherwise i could try this patch and try to get graphviz working with libpng-1.2.5. is there any easily way to get graphviz not working with libpng-1.2.5? ;)
Okie, I have managed to make graphviz build without libpng support for what it's worth ;). I compiles fine, but unfortunately I cannot really test it as I did not work wih this package before. I have asked Jan (from #11481) to test it and let me know. At list according to the docs it should be possible (as it says it was possible but they did not test it in some time) to use it without *any* of the graph libraries (jpeg and others). The ebuild (media-gfx/graphviz-1.8.10-r1) is both "hard" and key-masked at the moment (since presumably it is missing some functionality). !!!It should be unmasked prior to removal of libpng-1.0 from portage!!! obviously. Hannes: thanks for the pointer to the patch. I might look into it, but since now it seems to be working it's gonna be lower priority unless there agre "grave" issues about having png there. And yes, the libpng related error message was always the same on my memory. BTW, regarding you not aving problems with libpng-1.2.4: what profile were you testing it on (basically is it gcc-3.2* or gcc-2.95* based)? It looks like graphviz likes 2.95.3 better - it only started to compile wiht gcc-3.2 in 1.8 series I think. George
Yea, forgot to mention: doxigen, which depends on graphviz also biult fine afterwards. Thus this fix looks quite ligitimate at the moment. George
i'm using 1.4 profile with gcc-3.2.1 and glibc-2.3.1-r2.
I was looking at adding package 'kdevelop'. Apparently, kdevelop has graphviz and subequently libpng as dependencies. See below: ============================================================== dragon root # emerge -p kdevelop These are the packages that I would merge, in order. Calculating dependencies ...done! [ebuild N ] app-text/tetex-1.0.7-r11 [ebuild N ] app-text/jadetex-3.12 [ebuild N ] net-www/lynx-2.8.4.1d [ebuild N ] app-text/sgmltools-lite-3.0.3-r5 [ebuild N ] net-www/htdig-3.1.6-r4 [ebuild N ] app-text/enscript-1.6.3-r1 [ebuild N ] app-misc/glimpse-4.15 [ebuild N ] dev-util/cvs-1.11.2 [ebuild N ] dev-util/kdoc-2.0_alpha54 [ebuild N ] app-text/psutils-1.17 [ebuild N ] app-text/a2ps-4.13b-r4 [ebuild N ] app-text/ghostview-1.5-r1 [ebuild N ] app-doc/qt-docs-3.1.0 [ebuild N ] sys-devel/gdb-5.2.1 [ebuild N ] dev-util/kdbg-1.2.6 [ebuild U ] media-libs/libpng-1.0.12-r1 [ebuild N ] media-gfx/graphviz-1.8.10 [ebuild N ] app-doc/doxygen-1.2.18 [ebuild N ] app-doc/kdelibs-apidocs-3.1_rc3 [ebuild N ] dev-util/ctags-5.2.3 [ebuild N ] dev-util/kdevelop-3.0_alpha2 dragon root # ========================================================== What will happen to my system if I go ahead and emerge kdevelop? and What is the impact of the fix being discussed here on kdevelop?
try again, the new graphviz shouldnt depend on libpng 1.0
*** Bug 11844 has been marked as a duplicate of this bug. ***
I tried the new graphviz-ebuild. emerge kdelibs-apidocs results in many of: Error! Image `classKStyle__coll__graph.png' produced by dot is not a valid PNG! You should either select a different format (DOT_IMAGE_FORMAT in the config file) or install a more recent version of graphviz (1.7+) warning, language png not recognized, use one of: ps ps2 hpgl pcl mif pic gd gd2 gif jpg jpeg wbmp ismap imap cmap vtx mp fig svg svgz dot canon plain plain-ext It seems that we need a graphviz with png support.
*** Bug 11840 has been marked as a duplicate of this bug. ***
*** Bug 11606 has been marked as a duplicate of this bug. ***
Why doesn't autoconfig/config for KDE use libpng-config to determine which png library version to use ? kopete also fails because of this behavior ( png-dll-hell .P )
Hi guys >It seems that we need a graphviz with png support. Well, this is not too good. I just tried to make graphviz work with libong-1.2.5 following debian patch: 1. I tried applying the patch to 1.8.10. This applies mostly fine, though there are 3 rejects. Two are one-chunk rejects to Makfile.in's - easily remedied. However the 3rd one is a big reject to configure script - 170kb, not so quick to process :(. 2. Therefore I decided to test it against 1.8.9 version first. The patch applies cleanly, however compilation now fails with: gcc -march=pentium3 -O3 -pipe -fforce-addr -fomit-frame-pointer -falign-functions=4 -fprefetch-loop-arrays -fexpensive-optimizations -ffast-math -Wall -Wno-unknown-pragmas -o .libs/fontwheeltest fontwheeltest.o ./.libs/libgd.so /usr/lib/libfreetype.so /usr/lib/libjpeg.so -lz -lm -Wl,--rpath -Wl,/usr/lib/graphviz ./.libs/libgd.so: undefined reference to `gdImagePngCtx' ./.libs/libgd.so: undefined reference to `gdImageCreateFromPngCtx' collect2: ld returned 1 exit status So, it seems like this does not solve libpng problem :(. I will attach the ebuild (the only change is in src_unpack) and the patch in case anybody would be willing to take a look. George
Created attachment 6498 [details] graphviz-1.8.9.ebuild
Created attachment 6499 [details] files/graphviz-1.8.9.diff.bz2 BTW, is graphviz an indirect dependency via doxygen? Is it only needed to process documentation? In such case it may possible to make doc installation optional on "doc" usevar or completely remove doc installation (not too good, I know), as a transient solution (if there is a really desperate push for removing libpng-1.0 that is). George
graphviz is needed by doxygen which is needed by kdelibs-apidocs which is needed by kdevelop-3.x, so a "normal" kde user will not have any problems (as long as he don't install kdevelop) ;)
Why not mask libpng-1.2.5 and compile everything against libpng-1.0.12? That's what I have done and Opera, KDE and everything else I am using works without complaining about libpng.
No, masking libpng-1.2.5 won't work because all of the cups ebuilds require libpng >= 1.2.1.
As far as i can see the KDE application autoconf scripts _doesn't use_ libpng-config to determine correct version (and include paths of libpng to user for generic KDE applications. If this was done couldn't we have multiple libpng and the applications ( graphviz is an example ) which need an specific version should then be patched to select the older version until the application maintainers catch up ?
George: i still cannot reproduce this :(. maybe you can try http://www.graphviz.org/pub/graphviz/graphviz-current.tar.gz (that's the current version of graphviz, maybe this works with libpng-1.2.x, so we could add this into portage?).
Hi guys. I have checked the snapshot graphviz developers had out (Hannes: thanks for a tip) and the good news is that it seems to take libpng-1.2 Ok. Now, the bad news is that its build fails at seemingly random place, which is not quite unexpected, considering that this was a random development snapshot (they seem to just daily package their cvs tree). Thus no quick fix for us :(. I'll try to keep an eye on this location and periodically test it to see if any snapshot will give satisfactory results. In case of success I'll upload that snapshot to ibiblio and ask everybody to perform series of tests, while keeping the ebuild package.mask'ed. George
George: thx again :) another idea: since graphviz seems to be the package left which needs libpng-1.0.x, what about the following: -remove libpng-1.0.x ebuilds from portage -modify graphviz ebuild to fetch also old libpng, compile & install it (at least the files which are needed (libpng.so.2.1.0.12)) the other thing (which we should fix asap) is, libpng-1.0.x has SLOT=1.0, libpng-1.2.x has SLOT=1.2, but they both provide e.g. /usr/include/png.h, so they should have at least the same slot.
Hi Hannes. >the other thing (which we should fix asap) is, libpng-1.0.x has SLOT=1.0, >libpng-1.2.x has SLOT=1.2, but they both provide e.g. /usr/include/png.h, >so they should have at least the same slot. My understanding is that this is the root of the problem - libpng SLOTting was not done cleanly (and SLOTs were introduce to solve such problems in the first palce; so no, these *should* have different SLOTs). As such, it does not matter if libpng-1.0 is installed from within graphviz or via portage dependencies. In either case this will break things. The least damage route is to have libpng-1.0 be emerges as a dependency of graphviz and then to emerge libpng-1.2 on top of that. However this will probably break graphviz again and we are back to where we were starting off (the alternative is to have everythig else being broken by libpng-1.0). Thus IMHO the cleanest way to go here is to "repair" libpng-1.0 ebuild making it to install properly SLOTted version. However as I am not a maintainer of libpng I would like to ask the proper person to do it first (not sure who should be a "proper person" as the Changelog contains quite a few names: verwlist, seemant, mholzer?). At this point it seems to be easier to change libpng-1.0, as this is the one having the least number of dependencies. If this is done I should be able to make necessary changes to graphviz (if for example png.h has to be renamed to png-1.0.h). The only alternative is to just wait for the upstream to release a new version. The snapshot seems to go well about libpng-1.2, however the test I performed was not completely clean, as I did not get the compile to finish. Though I saw some compile messages utilising libpng and the failure message was *** No rule to make target `features/common', needed by `ast_common.h'. Stop. indicating incomplete code as the most likely cause. As for the timing - 1.8.9 was released in Aug, 1.8.10 was released in Oct, we can extrapolate to expect 1.8.11 to be released within few month, however one can never predict such things ;). George
George: i agree fixing libpng-1.0.x ebuild is the best way. adding mholzer and seemant to cc (verwilst already get mails for this bug cause he is part of kde@gentoo.org). seemant, mholzer: please fix libpng-1.0.x ebuilds. thanks.
george, hannes, I have an ebuild in testing locally that installs both version of libpng (the 1.0 for compatibility reasons). I'll put into portage shortly.
ok, libpng-1.0.15 is ~arch masked in portage, and doesn't clobber libpng-1.2* the clobbering was happening due to symlinks like png.h and pngconfig.h getting repointed with each different version (1.0 vs. 1.2) of libpng, so no symlinks in this 1.0.15. please test, hannes, george, et al.
thanks seemant. i get: >>> Unpacking libpng-1.0.15.tar.bz2 /usr/sbin/ebuild.sh: /usr/portage/media-libs/libpng/files/libpng-1.0.15-gentoo.diff: No such file or directory during emerge =libpng-1.0.15. some things in the 1.0.12 patch still not fixed in 1.0.15-vanilla. graphviz also links against libpng-1.2.x here.
Hi Hannes, Seemant. >>> Unpacking libpng-1.0.15.tar.bz2 >/usr/sbin/ebuild.sh: >/usr/portage/media-libs/libpng/files/libpng-1.0.15-gentoo.diff: No >such file or directory This is strange, as I updated my tree yesterday after reading seemants submission and got both libpng and the diff files. Also just rsynked again and checked - both files are there. emerge =libpng-1.0.15 worked fine and the stuff got installed in the proper places - does not overwrithe png.h and other stuff. Seemant, thanks! I have updated the graphviz ebuild. The graphviz-1.8.10-r2.ebuild should now link against the new libpng-1.0 location. The ebuild is committed and keymasked. I would like to request some testing (on my part I can report success with compiling doxygen, which depends on graphviz). George
i still do not get a libpng-1.0.15-gentoo.diff file :( according to webcvs (http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/media-libs/libpng/files/) it isn't in cvs.
hannes, I'm a doofus -- forgot to add it to cvs. it's there now.
People rejoice: libpng-1.0.x is no more! I just committed graphviz-1.9 which now compiles against libpng-1.2, which closes the gap, as this was the last app requiring the previous version. I would like to request some testing, as I think graphviz-1.9 should become stable before the 1.4 release, provided it passes the tests. This would finally cleanly close this libpng nuisance. Please post your test results to #15923 - I did not reopen this bug since no breakage occured and it is not really on topic (and sorry for using the closed bug, but it contained a nice list of emails of people who might be interested in the issue). George
Oops, sorry, small correction: please post test results (if you do them) to #16018. I copied wrong bug number last time :(. Hannes: thanks for catching this! George
