Summary: | =dev-libs/glib-2.36.3-r2 - src_prepare(): Failed Running autoconf: PKG_PROG_PKG_CONFIG not defined | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Markos Chandras (RETIRED) <hwoarang> |
Component: | New packages | Assignee: | Freedesktop bugs <freedesktop-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mgorny, mips, releng, staff |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Markos Chandras (RETIRED)
2013-08-14 15:23:58 UTC
PKG_PROG_PKG_CONFIG is defined in /usr/share/aclocal/pkg.m4, which should be provided by dev-util/pkgconfig. Do you have dev-util/pkgconfig installed? Or are you using some alternative implementation of virtual/pkgconfig? (In reply to Alexandre Rostovtsev from comment #1) > PKG_PROG_PKG_CONFIG is defined in /usr/share/aclocal/pkg.m4, which should be > provided by dev-util/pkgconfig. > > Do you have dev-util/pkgconfig installed? Or are you using some alternative > implementation of virtual/pkgconfig? Neither dev-util/pkgconfig nor virtual/pkgconfig is installed according to /var/db/pkg/ contents. This happens when building a MIPS64el stage3 so could it be a missing dep? glib depends on gtk-doc-am gtk-doc-am requires pkg.m4 from pkgconfig at runtime but gtk-doc-am cannot rdepend on pkgconfig due to circular dependencies, so it has a PDEPEND on virtual/pkgconfig instead. And apparently, when building your stage3, this results in portage scheduling virtual/pkgconfig after glib. I wonder how to fix this :/ (In reply to Alexandre Rostovtsev from comment #3) > glib depends on gtk-doc-am > > gtk-doc-am requires pkg.m4 from pkgconfig at runtime > > but gtk-doc-am cannot rdepend on pkgconfig due to circular dependencies, so > it has a PDEPEND on virtual/pkgconfig instead. > > And apparently, when building your stage3, this results in portage > scheduling virtual/pkgconfig after glib. > > I wonder how to fix this :/ I might be missing something but what's stopping you from adding virtual/pkgconfig as DEPEND to glib? (In reply to Markos Chandras from comment #4) > I might be missing something but what's stopping you from adding > virtual/pkgconfig as DEPEND to glib? circular dependency: dev-util/pkgconfig[-internal-glib] rdepends on glib. Possible solution: split pkg.m4 out of pkgconfig into a separate package (maybe "pkgconfig-common" or "pkg-am"). CC'ing releng@ because stable arches will hit this problem as soon as glib-2.36.3-r2 is stabilized and pulled into stages. MIPS does only ~arch so we already have this problem. CC'ing mips@ too to make the rest of the team aware of the problem For now, we can mask 2.36.X in stages and ship 2.34 instead. Turns out we already *had* a fix for this exact problem in glib-2.34.x ebuilds (adding pkgconfig's source tarball to glib's SRC_URI and using pkg.m4 from there), but it was removed for some reason during the 2.36.x bump. I've restored it with a comment explaining why it is necessary. Should be fixed now :) + 15 Aug 2013; Alexandre Rostovtsev <tetromino@gentoo.org> + glib-2.36.3-r2.ebuild: + Restore the pkg.m4 hack from 2.34.x to prevent stage3 build failure (bug + #481056, thanks to Markos Chandras). sorry, this not solving stage3 failures if pkgconf set as default instead of pkgconfig. This looks rather strange, why not to use a proper one (either pkg-config or pkgconf) to solve this issue. Issue is, with this fix, stages built with pkgconf now trying to use pkgconfig... (In reply to Oleg from comment #9) > sorry, this not solving stage3 failures if pkgconf set as default instead of > pkgconfig. This looks rather strange, why not to use a proper one (either > pkg-config or pkgconf) to solve this issue. Issue is, with this fix, stages > built with pkgconf now trying to use pkgconfig... Adding the tarball containing pkg.m4 to SRC_URI and using it from the ebuild *is the proper fix* It doesn't matter if you run pkgconf, or pkgconfig, or pkgconfig-openbsd since the pkg.m4 that provides PKG_PROG_PKG_CONFIG is always copies to the glib's m4macros/ subdirectory where it's catched up by the build system So you have to be more explicit what your problem really is, the given description doesn't make sense |