Since upgrade to libpng-1.4.2, gnumeric build fails with CCLD libspreadsheet.la /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpng12 Reproducible: Always
For gnome problems and libpng, try bulding glade, cairo, pango, and gtk+ first. Then you can do something like hacky like: find /usr/lib64 -name '*.la' |xargs grep lpng If you see -lpng12 lines there, those are broken .la files. For example, remove them or change with -lpng14. Or re-emerge the problematic package it belongs to, yes... we need a tool for this :/ You get to blame sys-devel/libtool for sucking :)
*** Bug 319099 has been marked as a duplicate of this bug. ***
*** Bug 319029 has been marked as a duplicate of this bug. ***
Reopen for easier finding, I'm sure it helps bug-wranglers...
*** Bug 319179 has been marked as a duplicate of this bug. ***
AT YOUR OWN RISK: # find /usr/lib -name '*.la' | xargs sed -i -e '/^dep/s:-lpng12:-lpng14:' # emerge -1 cairo pango libglade gtk+ or lib64
*** Bug 319103 has been marked as a duplicate of this bug. ***
*** Bug 319089 has been marked as a duplicate of this bug. ***
As was mentioned in the https://bugs.gentoo.org/show_bug.cgi?id=319101 thread the solution isn't difficult, but is very time consuming. Before updating from to libpng-1.2 to libpng-1.4 make sure that you have fetched any other files that need to be updated by running "emerge -euNDf world". You're going to need these files in advance because as mentioned updating is going to temporarily break many applications linked to it, especially if you're a Gnome desktop user. Now it's ok to 'emerge --oneshot libpng'. Then run 'lafilefixer --justfixit'. Now you're ready for the "big rebuild". I use KDE even so I had to rebuild 70 apps. Those of you running Gnome, if you're no longer able to use or get to a terminal in X then just 'Ctrl-Alt-F1' to drop to a shell. Then run 'revdep-rebuild'. When finished your system should be sane again. Beware, that you may have to rebuild over 100 apps including Open Office if it was built with Gnome support. After this is all done 'Ctrl-Alt-F7' will get you back into your desktop environment. I hope this helps. Ciao
Maybe lafilefixer needs a tweak, too. I could swear I ran it before running revdep-rebuild, but things broke until I followed Comment #6 prior to rerunning revdep-rebuild. Not done rebuilding the 100+ packages, but for now: Works for me.
I've just solved the issue and I didn't have to rebuild everything. On my machine libpng-1.4 was automatically installed to the separate slot. libpng-1.2 stayed in libpng:1.2 slot. At first I ran revdep-rebuild and it displayed like 70 packages, I've rebuilt a couple of them and then it crashed when looking for libpng12.la. So I ran lafilefixer --justfixit and then revdep-rebuild should zero packages to rebuild. Obviously some of my packages must be linked against libpng12.la, but I don't mind until it works :-) I didn't do a thing from comment 6. Oleg
I thought sedding about with the .la files may be a little risky, so I used this to rebuild all affected packages. emerge --oneshot --jobs 1 --keep-going $(qfile -qC $(find /usr/lib64 -name '*.la' | xargs grep -- -lpng12 | awk -F: '{print $1}')) You may need to run it more than once before it completes without errors.
I can confirm on my system that s/png12/png14/ in /usr/lib/*.la allowed the rest of the packages to compile after one pass of 'lafilefixer --justfixit' and 'revdep-rebuild -- --keep-going'. I did it by hand though, as I'm too cowardly to run sed in /usr/lib!
The ebuild info now mentions a script you can run if lafilefixer and revdep-rebuild fail, which executes the above sed funkiness for you: /usr/sbin/libpng-1.4.x-update.sh In my case, I had to. As to Comment #9, I generally avoid all this terminal switching by just emerging everything from GNU Screen or tmux. For those who haven't tried it, I highly suggest it. At the end, if you need to, just restart X and reconnect to your Screen session, with a finished emerge. This libpng upgrade really put a dent in my day =/ Thanks for all the great info guys!
Finally closing. Fixed by running the shipped /usr/sbin/libpng-1.4.x-update.sh script.
*** Bug 319755 has been marked as a duplicate of this bug. ***
*** Bug 319879 has been marked as a duplicate of this bug. ***
*** Bug 320011 has been marked as a duplicate of this bug. ***
*** Bug 320025 has been marked as a duplicate of this bug. ***
*** Bug 320027 has been marked as a duplicate of this bug. ***
*** Bug 320319 has been marked as a duplicate of this bug. ***
*** Bug 320229 has been marked as a duplicate of this bug. ***
*** Bug 320069 has been marked as a duplicate of this bug. ***
*** Bug 320403 has been marked as a duplicate of this bug. ***
Note installing libpng:1.2 and libpng:0, then revdep-rebuild (or reconcilio for paludis) --library libpng12.so.0, then uninstall libpng:1.2 will also work.
*** Bug 321081 has been marked as a duplicate of this bug. ***
*** Bug 321113 has been marked as a duplicate of this bug. ***
*** Bug 321167 has been marked as a duplicate of this bug. ***
*** Bug 326235 has been marked as a duplicate of this bug. ***
*** Bug 319123 has been marked as a duplicate of this bug. ***
*** Bug 326349 has been marked as a duplicate of this bug. ***
Got this bug when update. Made: # find /usr/lib64 -name "*.la" | xargs sed -i -e "/^dep/s:-lpng12:-lpng14:" # emerge -1 cairo pango libglade gtk+ but on compilation media-gfx/graphviz-2.26.0 got: CCLD libgvplugin_gd_C.la CCLD libgvplugin_gd.la /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpng12 collect2: ld returned 1 exit status distcc[20342] ERROR: compile (null) on localhost failed make[3]: *** [libgvplugin_gd.la] Ошибка 1 make[3]: Leaving directory `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0/plugin/gd' make[2]: *** [all-recursive] Ошибка 1 make[2]: Leaving directory `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0/plugin' make[1]: *** [all-recursive] Ошибка 1 make[1]: Leaving directory `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0' make: *** [all] Ошибка 2 All *.la files in /usr/lib64/ have dependence only from -lpng14 and I cann't understand where libtool found old dependence.
I upgraded to libpng14 months ago and it went well. Today gnuplot failed to compile and I ended up reading this bug report. 15:51:26 root jerome/ equery list libpng [ Searching for package 'libpng' in all categories among: ] * installed packages [I--] [ ] media-libs/libpng-1.2.44 (1.2) [I--] [ ] media-libs/libpng-1.4.3 (0) I did: revdep-rebuild /usr/sbin/libpng-1.4.x-update.sh lafilefixer --justfixit # find /usr/lib64 -name '*.la' | xargs sed -i -e '/^dep/s:-lpng12:-lpng14:' # emerge -1 cairo pango libglade gtk+ (Maybe in a different order, and possibly several times each item). Anyway, emerge =sci-visualization/gnuplot-4.4.2 [...] x86_64-pc-linux-gnu-g++ -O2 -pipe -Wl,-O1 -Wl,--as-needed -L/usr/lib64 -Wl,-O1 -L/usr/lib64 -o gnuplot alloc.o axis.o binary.o breaders.o bitmap.o color.o command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o gp_cairo.o gp_cairo_helpers.o -lreadline -lncurses -lz -lgd -lXpm -lX11 -ljpeg -lfreetype -lpng12 -lz -lm -ljpeg -lpdf -lreadline -lreadline -lreadline -lreadline -lm -pthread -lz -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpng12
(In reply to comment #33) > I upgraded to libpng14 months ago and it went well. Today gnuplot failed to > compile and I ended up reading this bug report. > > 15:51:26 root jerome/ equery list libpng > [ Searching for package 'libpng' in all categories among: ] > * installed packages > [I--] [ ] media-libs/libpng-1.2.44 (1.2) > [I--] [ ] media-libs/libpng-1.4.3 (0) Try emerge -C =libpng-1.2.44 && emerge gnuplot
Thank you, it worked. (Side-effect: recompiling 40 packages.) (In reply to comment #34) > Try > emerge -C =libpng-1.2.44 && emerge gnuplot >
(In reply to comment #32) > Got this bug when update. Made: > > # find /usr/lib64 -name "*.la" | xargs sed -i -e "/^dep/s:-lpng12:-lpng14:" > # emerge -1 cairo pango libglade gtk+ > > but on compilation media-gfx/graphviz-2.26.0 got: > > CCLD libgvplugin_gd_C.la > CCLD libgvplugin_gd.la > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: > cannot find -lpng12 > collect2: ld returned 1 exit status > distcc[20342] ERROR: compile (null) on localhost failed > make[3]: *** [libgvplugin_gd.la] Ошибка 1 > make[3]: Leaving directory > `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0/plugin/gd' > make[2]: *** [all-recursive] Ошибка 1 > make[2]: Leaving directory > `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0/plugin' > make[1]: *** [all-recursive] Ошибка 1 > make[1]: Leaving directory > `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0' > make: *** [all] Ошибка 2 > > All *.la files in /usr/lib64/ have dependence only from -lpng14 and I cann't > understand where libtool found old dependence. > I had to emerge media-libs/gd to get rid of the error. Run 'gdlib-config --libs' to see if it contains '-lpng12'. Mine did.
(In reply to comment #36) > (In reply to comment #32) > > Got this bug when update. Made: > > > > # find /usr/lib64 -name "*.la" | xargs sed -i -e "/^dep/s:-lpng12:-lpng14:" > > # emerge -1 cairo pango libglade gtk+ > > > > but on compilation media-gfx/graphviz-2.26.0 got: > > > > CCLD libgvplugin_gd_C.la > > CCLD libgvplugin_gd.la > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: > > cannot find -lpng12 > > collect2: ld returned 1 exit status > > distcc[20342] ERROR: compile (null) on localhost failed > > make[3]: *** [libgvplugin_gd.la] Ошибка 1 > > make[3]: Leaving directory > > `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0/plugin/gd' > > make[2]: *** [all-recursive] Ошибка 1 > > make[2]: Leaving directory > > `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0/plugin' > > make[1]: *** [all-recursive] Ошибка 1 > > make[1]: Leaving directory > > `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0' > > make: *** [all] Ошибка 2 > > > > All *.la files in /usr/lib64/ have dependence only from -lpng14 and I cann't > > understand where libtool found old dependence. > > > > I had to emerge media-libs/gd to get rid of the error. > Run 'gdlib-config --libs' to see if it contains '-lpng12'. Mine did. > I just got the same thing. Ran 'gdlib-config --libs' and found lpng12 also. After rebuild, it was no longer there. (In reply to comment #36) > (In reply to comment #32) > > Got this bug when update. Made: > > > > # find /usr/lib64 -name "*.la" | xargs sed -i -e "/^dep/s:-lpng12:-lpng14:" > > # emerge -1 cairo pango libglade gtk+ > > > > but on compilation media-gfx/graphviz-2.26.0 got: > > > > CCLD libgvplugin_gd_C.la > > CCLD libgvplugin_gd.la > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: > > cannot find -lpng12 > > collect2: ld returned 1 exit status > > distcc[20342] ERROR: compile (null) on localhost failed > > make[3]: *** [libgvplugin_gd.la] Ошибка 1 > > make[3]: Leaving directory > > `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0/plugin/gd' > > make[2]: *** [all-recursive] Ошибка 1 > > make[2]: Leaving directory > > `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0/plugin' > > make[1]: *** [all-recursive] Ошибка 1 > > make[1]: Leaving directory > > `/tmp/portage/media-gfx/graphviz-2.26.0/work/graphviz-2.26.0' > > make: *** [all] Ошибка 2 > > > > All *.la files in /usr/lib64/ have dependence only from -lpng14 and I cann't > > understand where libtool found old dependence. > > > > I had to emerge media-libs/gd to get rid of the error. > Run 'gdlib-config --libs' to see if it contains '-lpng12'. Mine did. > I had same problem and checked gd. It was still pointing to lpng12 even though it was not installed on the system. I rebuilt it and ran revdep-rebuild and it all worked sanely. Is this something that should be addressed by the devs? When I ran revdep-rebuild before the gd rebuild, it did not catch the problem. Just seems it may be a problem with gd after the upgrade of lping.
*** Bug 349902 has been marked as a duplicate of this bug. ***
*** Bug 383433 has been marked as a duplicate of this bug. ***
*** Bug 383449 has been marked as a duplicate of this bug. ***
To anyone stumbling over here because of "missing -lpng14". Run this command to identify broken files: # find /usr/ -name '*.la' -exec grep png14 {} + Re-emerge the packages the files belong to, or edit them by hand and replace "-lpng14" with "-lpng". These packages that install such .la files shouldn't propably install them at all, so you might even want to open a bug against them... for installing useless .la files, if you know howto identify them.
*** Bug 383619 has been marked as a duplicate of this bug. ***
*** Bug 383653 has been marked as a duplicate of this bug. ***
Hi Samuli, to comment 41, is it not the duty of lafilfilefixer to do this job? Regards Juergen
Sorry for the typos. I meant lafilefixer.
(In reply to comment #44) > to comment 41, is it not the duty of [lafilefixer] to do this job? As fas as I understand things, lafilefixer will only translate references to libfoo.so and libfoo.la files back to -lfoo linker arguments. As libpng has libpng14.so instead of libpng.so.1.4, the corresponding flag is still -lpng14, therefore will still include the version number. That's a special case, other libraries usually don't do this. So I wouldn't consider dealing with this the task of lafilefixer. (In reply to comment #41) > # find /usr/ -name '*.la' -exec grep png14 {} + Offering my own alternative, to actually remerge the affected packages: emerge -a1 --keep-going $(find /usr/lib* /lib* -name '*.la' -print0 \ | xargs -0 grep -l png14 | while read f; do qfile -C -v "$f" \ | awk '{print $1}'; done | sort -u | sed 's:^:=:')
*** Bug 383781 has been marked as a duplicate of this bug. ***
*** Bug 383905 has been marked as a duplicate of this bug. ***
*** Bug 383909 has been marked as a duplicate of this bug. ***
*** Bug 384081 has been marked as a duplicate of this bug. ***
*** Bug 384101 has been marked as a duplicate of this bug. ***
I update libpng from 1.4 to 1.5 and gnome-settings-daemon is an only package build against libpng which failed to reemerge. So two questions: 1. Does this bug really fixed? 2. If all okay with libpng (all packages except one reemerged successfully) why bug 384101 is marked as duplicate of this bug?
(In reply to comment #53) > 2. If all okay with libpng (all packages except one reemerged successfully) why > bug 384101 is marked as duplicate of this bug? As comment #41 points out, that single package probably won't re-emerge because some OTHER package still has a bad libpng reference in one of its *.la files. So find that file, and re-emerge that package before repeating the failing emerge. If you feel like it, file a bug report asking for that package to not install the *.la file in the first place. I have to agree, though, that this kind of manual intervention isn't exactly a solved issue by my book either. But there is little that libpng can do about it (at least no automatic solution has been suggested here, has there?), as this would have to be dealt with by package managers. See e.g. bug #287318 requesting that portage deal with *.la files. (In reply to comment #15) > Finally closing. Fixed by running the shipped /usr/sbin/libpng-1.4.x-update.sh > script. Should we have a matching libpng-1.5.x-update.sh as well? Can't find the source for the 1.4.x one either, so I'm not sure what exactly it did. But something along the lines of comment 46, probably with fewer external deps (on app-portage/portage-utils for qfile in particular) might be useful.
I'm on Gentoo Prefix, and I have no /usr/sbin/libpng-1.4.x-update.sh. Or anything remotely like it.
*** Bug 384269 has been marked as a duplicate of this bug. ***
We are using this bug to collect another bugs with insufficient data which are clearly caused by broken libtool files (.la) And by insufficient data I mean bugs that don't mention the specific .la file that has the -lpng14 reference, so that such bug could be assigned to the maintainer owning the package the .la file belongs to. One .la file, one package, one bug. A massive list in one bug won't help as then we can't assign it properly. Such package propably needs it's .la files removed, USE=static-libs added, and other general cleanup. And as we don't expect every single user to know howto identify these properly, and we don't have time to explain it to everyone comprehensibly, you are forwarded here for workaround instead. If you are REALLY intrested in helping minimizing this impact, I suggest you start with reading Flameeyes blog: http://blog.flameeyes.eu/ Find out every Article it has on libtool, .la files, and so forth. Read them good. Once you understand the issue entirely, you can start filing bugs about "category/package installs unnecessary .la files, causing problems for libpng upgrade" And if you don't do this properly, maintainers will just get very annoyed. I hope that clears up why you have ended up here, instead of something else. It by no means, are meant as an deliberate ignore on anyone.
(In reply to comment #55) > I'm on Gentoo Prefix, and I have no /usr/sbin/libpng-1.4.x-update.sh. Or > anything remotely like it. Comment #41 and Comment #46 instead of that script.
(In reply to comment #57) > If you are REALLY intrested in helping minimizing this impact, I suggest you > start with reading Flameeyes blog. > Find out every Article it has on libtool, .la files, and so forth. http://blog.flameeyes.eu/tag/libtool and http://blog.flameeyes.eu/tag/lafiles (In reply to comment #58) > Comment #41 and Comment #46 instead of that script. If there is to be no script, how do you plan to handle stabilization of libpng-1.5? While I agree that the root cause lies in the individual packages and their *.la files, I guess it is highly unlikely that all those individual packages will be fixed, the fixed versions stabilized, and users install those fixed packages, before libpng gets stabilized. And hoping for all stable users to find this bug on their own doesn't look too good. So I suggest you should include some advice in the libpng pkg_postinst(), perhaps based on EAPI=4 ${REPLACING_VERSIONS} being <1.5 to avoid issuing the same message over again and again. At the very least, the message should point users at this bug here. Even better, it should print instructions on how to fix things, and as comment #41 requires manual work to process its output, and comment #46 is rather a lengthy command, having a script instead might be better.
*** Bug 384139 has been marked as a duplicate of this bug. ***
(In reply to comment #59) > If there is to be no script, how do you plan to handle stabilization of > libpng-1.5? Portage news item[1] when 1.5 goes stable, not before, as ~arch users should know their way around this without any help. [1] http://www.gentoo.org/proj/en/glep/glep-0042.html
> as ~arch users should know their way around this without any help. Since when has Prefix had a stable branch?
*** Bug 384403 has been marked as a duplicate of this bug. ***
*** Bug 384437 has been marked as a duplicate of this bug. ***
*** Bug 384503 has been marked as a duplicate of this bug. ***
*** Bug 384633 has been marked as a duplicate of this bug. ***
*** Bug 384829 has been marked as a duplicate of this bug. ***
Adding alias for faster marking of duplicates
*** Bug 384931 has been marked as a duplicate of this bug. ***
*** Bug 384989 has been marked as a duplicate of this bug. ***
*** Bug 385203 has been marked as a duplicate of this bug. ***
*** Bug 385419 has been marked as a duplicate of this bug. ***
Hi Samuli, is Bug 385203 really a duplicate of this bug? At least it does not depend on broken .la files. Thus emerge -a1 --keep-going $(find /usr/lib* /lib* -name '*.la' -print0 \ | xargs -0 grep -l png14 | while read f; do qfile -C -v "$f" \ | awk '{print $1}'; done | sort -u | sed 's:^:=:') does not help, to solve the problem of Bug 385203, while emerge -a1 --keep-going $(find /usr/lib* /lib* -name '*.so' -exec bash -c "if [ -x {} ]; then if ldd {} | grep png14 > /dev/null; then qfile -vC {} | cut -f1 -d' '; fi; fi;" \; | sort -u | sed 's:^:=:') solved the issue of Bug 385203.
I'm currently stuck with the libpng upgrade, gnome-media-2.32.0-r1 fails to rebuild (the usual, cannot find -lpng14), but it seems all the other packages picked up by the various one-liners given here depend on it and either also fail or get skipped due to unsatisfied dependencies. I've tried running lafilefixer --justfixit but that didn't seem to fix anything. Does anyone know how to proceed?
(In reply to comment #74) > Does anyone know how to proceed? Find out what lafiles it is using that provides this broken link instruction. You might try something along these lines: emerge -an dev-util/strace strace -ff -e open -o /tmp/emerge.strace \ ebuild /usr/portage/gnome-extra/gnome-media/gnome-media-2.32.0-r1.ebuild \ clean install grep -v ENOENT /tmp/emerge.strace.* | cut -d\" -f2 | sort -u | \ grep '^/.*\.la$' | xargs grep png What this does: 1. While trying to build the package, use strace to log every use of the open system call to a file /tmp/emerge.strace.<PID> 2. In all those files, look for succeeding open calls referencing la files using absolute paths. 3. In all of these la files, find those mentioning png. You should feed the found la file to "qfile -v" from app-portage/portage-utils to determine the package it belongs to. If emerging that package really doesn't work due to cyclic dependencies, you might try renaming the lafile, and if that makes things work, removing it afterwards. Don't forget to remove the strace output files as well when you're done.
(In reply to comment #75) > (In reply to comment #74) > > Does anyone know how to proceed? > > Find out what lafiles it is using that provides this broken link instruction. Thanks! It turned out to be a .la file installed by dev-util/glade (libgladeui-1.la) that was causing gnome-media to fail
*** Bug 385891 has been marked as a duplicate of this bug. ***
(In reply to comment #76) > (In reply to comment #75) > > (In reply to comment #74) > > > Does anyone know how to proceed? > > > > Find out what lafiles it is using that provides this broken link instruction. > > Thanks! It turned out to be a .la file installed by dev-util/glade > (libgladeui-1.la) that was causing gnome-media to fail I've removed the file now from the ebuild, it's useless, rm -f it.
*** Bug 386659 has been marked as a duplicate of this bug. ***
*** Bug 387405 has been marked as a duplicate of this bug. ***
*** Bug 387489 has been marked as a duplicate of this bug. ***
*** Bug 387591 has been marked as a duplicate of this bug. ***
*** Bug 387723 has been marked as a duplicate of this bug. ***
*** Bug 387857 has been marked as a duplicate of this bug. ***
*** Bug 387861 has been marked as a duplicate of this bug. ***
*** Bug 388139 has been marked as a duplicate of this bug. ***
*** Bug 388167 has been marked as a duplicate of this bug. ***
For the record and for those who want to investigate this further: This is the result of find /usr/lib64 -name '*.la' |xargs grep lpng14 2> /dev/null | sed 's/\:.*//' | xargs equery -q b | sort | uniq on my machine, while looking for possible libpng14 la-files: dev-cpp/libgnomecanvasmm-2.26.0 gnome-base/libgnomecanvas-2.30.3 gnome-base/libgnomeui-2.24.5 media-libs/libexif-gtk-0.3.5-r2 net-print/gutenprint-5.2.6 x11-libs/gtkglext-1.2.0 x11-libs/gtksourceview-1.8.5-r1 x11-libs/gtksourceview-2.10.5-r1 x11-themes/gtk-engines-candido-0.9.1 x11-themes/gtk-engines-rezlooks-0.6
*** Bug 388513 has been marked as a duplicate of this bug. ***
(In reply to comment #88) > media-libs/libexif-gtk-0.3.5-r2 Fixed this one.
While doing a emerge --update --deep world /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpng14 collect2: ld returned 1 exit status make[3]: *** [libkeyboard.la] Error 1 make[3]: Leaving directory `/var/tmp/portage/gnome-base/gnome-settings-daemon-2.32.1-r2/work/gnome-settings-daemon-2.32.1/plugins/keyboard' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/gnome-base/gnome-settings-daemon-2.32.1-r2/work/gnome-settings-daemon-2.32.1/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/gnome-base/gnome-settings-daemon-2.32.1-r2/work/gnome-settings-daemon-2.32.1' make: *** [all] Error 2 * ERROR: gnome-base/gnome-settings-daemon-2.32.1-r2 failed (compile phase): * emake failed I then tried emerge libpng which re installs libpng-1.5.5 ok but tells me that "Old versions of installed libraries were detected on your system" and I should run revdep-rebuild --library '/usr/lib64/libpng14.so.14' When I do this it fails to emerge gnome-settings-daemon-2.32.1 with the same problem. What can I do to get this working?
Executing the following in /usr/lib64 sorted it out for me. find -name \*.la -exec sed -i -e 's/-lpng14/-lpng15/' '{}' \;
(In reply to comment #92) > Executing the following in /usr/lib64 sorted it out for me. > > find -name \*.la -exec sed -i -e 's/-lpng14/-lpng15/' '{}' \; OK, a safer way would be to find the relevant packages with this command and then rebuild them: find /usr/lib64 -name '*.la' |xargs grep lpng14 2> /dev/null | sed 's/\:.*//' | xargs equery -q b | sort | uniq
*** Bug 388789 has been marked as a duplicate of this bug. ***
I ran into this problem with emerge @preserved-rebuild, all of which failed to build. As follows: net-print/gnome-cups-manager-0.33-r2 gnome-extra/gnome-media-2.32.0-r1 gnustep-base/gnustep-gui-0.18.0 sci-astronomy/celestia-1.6.1 I'm running find /usr/lib -name '*.la' |xargs grep lpng14 2> /dev/null | sed 's/\:.*//' | xargs equery -q b | sort | uniq now... But that still leaves the matter of always getting the preserved rebuild message after updating with emerge. What to do?
That hack did not fix things for me vis. emerge @preserved-rebuild. Any ideas?
*** Bug 388841 has been marked as a duplicate of this bug. ***
*** Bug 390019 has been marked as a duplicate of this bug. ***
*** Bug 390023 has been marked as a duplicate of this bug. ***
*** Bug 390015 has been marked as a duplicate of this bug. ***
*** Bug 394723 has been marked as a duplicate of this bug. ***
*** Bug 394959 has been marked as a duplicate of this bug. ***
*** Bug 398997 has been marked as a duplicate of this bug. ***
*** Bug 403773 has been marked as a duplicate of this bug. ***
So here is the link (again) for people still ending up with this problem: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-news/2011/2011-10-15-libpng15/2011-10-15-libpng15.en.txt?revision=57&view=markup
*** Bug 406459 has been marked as a duplicate of this bug. ***
*** Bug 422531 has been marked as a duplicate of this bug. ***
*** Bug 432648 has been marked as a duplicate of this bug. ***
None of the above solutions works for me! I've to build mldonkey without gd support to complete tre process with success: USE="-gd" emerge -v net-p2p/mldonkey Installed versions: 3.1.0(12:10:19 PM 10/09/2012)(bittorrent fasttrack gnutella gtk magic ocamlopt -doc -gd -guionly) Somebody can help to understand? I've tried to rebuild media-libs/gd but mldonkey fails in the same place. Thank Alex
*** Bug 437650 has been marked as a duplicate of this bug. ***
*** Bug 450366 has been marked as a duplicate of this bug. ***
*** Bug 472050 has been marked as a duplicate of this bug. ***
*** Bug 473956 has been marked as a duplicate of this bug. ***
*** Bug 475220 has been marked as a duplicate of this bug. ***
I am not aware of any .la files on my system; haven't they been replaced by some other mechanism around 2012? Still I got "ld: cannot find -lpng15" when building app-office/dia-0.97.2-r1, with media-libs/libpng-1.5.16 installed. (BTW, I had to install a =media-libs/libpng-1.5* manually; with just =media-libs/libpng-1.6* installed the dia ebuild wouldn't complain, but the build would fail – should I file this (broken dependency?) as a bug with the dia ebuild?) In my case the following workaround helped: # cd /usr/lib64 # ln -s libpng15.so.15 libpng15.so This idea came to my mind as there was a symlink libpng16.so to libpng16.so.16.3.0, as provided by =media-libs/libpng-1.6.3-r1.
(In reply to Christoph Lange from comment #115) > In my case the following workaround helped: > > # cd /usr/lib64 > # ln -s libpng15.so.15 libpng15.so Sorry, reading https://bugs.gentoo.org/show_bug.cgi?id=473956#c1 made me realize that this is not the right way – indeed some obsolete .la files with outdated dependency_libs information were around.
*** Bug 491432 has been marked as a duplicate of this bug. ***
*** Bug 510252 has been marked as a duplicate of this bug. ***
