Summary: | dev-util/pkgconfig-0.26 doesn't check for Requires.private: fatal error: glib.h: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Justin Lecher (RETIRED) <jlec> |
Component: | Current packages | Assignee: | Freedesktop bugs <freedesktop-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | hans, markodevelop, tetromino |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
/var/log/portage/build/gnome-base/gconf-2.32.4:20110919-154739.log
/var/tmp/portage/gnome-base/gconf-2.32.4/work/GConf-2.32.4/config.log |
Description
Justin Lecher (RETIRED)
2011-09-19 15:50:54 UTC
Created attachment 287013 [details]
/var/log/portage/build/gnome-base/gconf-2.32.4:20110919-154739.log
build.log
The first question is obviously config.log (given the circumstances, most likely ends up with something pkg-config related). Created attachment 287017 [details]
/var/tmp/portage/gnome-base/gconf-2.32.4/work/GConf-2.32.4/config.log
Absolutly right
rebuilding gdk-pixbuf helped. As discussed on IRC, this is caused by the following chain of events: 1. Justin happened to have an invalid gdk-pixbuf-2.0.pc file after the libpng upgrade: Name: GdkPixbuf Description: Image loading and scaling Version: 2.24.0 Requires: gobject-2.0 Requires.private: gmodule-no-export-2.0 libpng14 Libs: -L${libdir} -lgdk_pixbuf-2.0 Libs.private: -lm Cflags: -I${includedir}/gdk-pixbuf-2.0 2. gconf's configure checked for "glib-2.0 > 2.14.0 gio-2.0 >= 2.25.9 gthread-2.0 gmodule-2.0 >= 2.7.0 gobject-2.0 >= 2.7.0 ORBit-2.0 >= 2.4.0 gtk+-2.0 >= 2.14" 3. gtk+-2.0.pc pulls in gdk-pixbuf-2.0 via "Requires:" 4. As expected, "pkg-config --cflags" died with an error. However, for unknown reasons, "pkg-config --libs" worked! So "PKG_CHECK_MODULES(DEPENDENT_WITH_GTK, ...)" succeeded, configure blithely continued on, and then make failed because DEPENDENT_WITH_GTK_LIBS was defined and DEPENDENT_WITH_GTK_CFLAGS was not. Conclusions: a. This is not a bug in gconf. The ultimate cause is not running revdep-rebuild after the libpng upgrade. So marking this "resolved invalid". b. Under some circumstances, pkg-config --libs can succeed when --cflags fails. IMHO, such behavior is a bug, and merits further investigation. (In reply to comment #5) > > b. Under some circumstances, pkg-config --libs can succeed when --cflags fails. > IMHO, such behavior is a bug, and merits further investigation. So it is a bug and we should find a solution for that IIRC, there were changes regarding this very problem on pkg-config 0.25 -> 0.26...in pkg.m4 macro - http://cgit.freedesktop.org/pkg-config/commit/?id=4366f5842fc6ca0432c5dfa6b6dcb20d83aa4ee8. So, no, short of eautoreconf-ing everything, nothing reasonable can be done about it. (In reply to comment #7) > IIRC, there were changes regarding this very problem on pkg-config 0.25 -> > 0.26...in pkg.m4 macro - > http://cgit.freedesktop.org/pkg-config/commit/?id=4366f5842fc6ca0432c5dfa6b6dcb20d83aa4ee8. > > So, no, short of eautoreconf-ing everything, nothing reasonable can be done > about it. Actually, there is a reasonable solution: "pkg-config --exists" should not skip checking Requires.private. That would have been enough to catch Justin's gconf issue. Well, if I'm reading the old ChangeLog correctly, it's not that simple - see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475031. *** Bug 383839 has been marked as a duplicate of this bug. *** (In reply to comment #9) > Well, if I'm reading the old ChangeLog correctly, it's not that simple - see > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475031. That bug should be fixed in pkgconfig-0.26 :-/ No, I've meant that change was introduced *on purpose* to solve that bug. ...and it was introduced long before 0.26 too. I think we can't to much more here no? *** Bug 385829 has been marked as a duplicate of this bug. *** (In reply to comment #14) > I think we can't to much more here no? Maybe add a tool, something like revdep-rebuild, to check /usr/lib/pkgconfig for inconsistencies? ignoring the wider problem... nobody should be hitting this with gdk-pixbuf and libpng as it's already fixed, *gdk-pixbuf-2.24.0-r1 (15 Sep 2011) 15 Sep 2011; Samuli Suominen <ssuominen@gentoo.org> +gdk-pixbuf-2.24.0-r1.ebuild: Use libpng.pc instead of versioned pkg-config file to generate Requires.private: libpng instead of versioned one. This will avoid some problems with libpng14 to libpng15 upgrade. unless mixing stable with ~arch of course, but that's unsupported anyway We can add !<x11-libs/gdk-pixbuf-2.24.0-r1 to libpng's ebuild to force the order of emerge by blocker. Overkill, or needed? (In reply to comment #18) > We can add !<x11-libs/gdk-pixbuf-2.24.0-r1 to libpng's ebuild to force the > order of emerge by blocker. Overkill, or needed? http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/libpng/libpng-1.5.5.ebuild?r1=1.1&r2=1.2 (In reply to comment #18) > We can add !<x11-libs/gdk-pixbuf-2.24.0-r1 to libpng's ebuild to force the > order of emerge by blocker. Overkill, or needed? It would be quite helpful. Running revdep-rebuild after the libpng upgrade can add gdk-pixbuf to the rebuild list after packages whose build systems, through one or more levels of pkgconfig indirection, will fail when reading a broken gdk-pixbuf-2.0.pc. Nice, thanks a lot for the work, I guess we cannot do more now ;) |