At least since pkgconfig-0.22 packages listed in Requires.private are ensured to be present during pkg-config --exists checks, this inherently also means PKG_CHECK_MODULES m4 macro. What this means in practice for us is, that for example everything doing a check for gtk+-2.0 (basically everything DEPENDing on gtk+:2) build-time depends on renderproto, because if renderproto isn't present the following happens: configure:22926: error: Package requirements (glib-2.0 gtk+-2.0) were not met: Package renderproto was not found in the pkg-config search path. Perhaps you should add the directory containing `renderproto.pc' to the PKG_CONFIG_PATH environment variable Package 'renderproto', required by 'Xrender', not found This actually currently is a bad example, because libXrender RDEPEND's on renderproto - but that it probably does mostly due to this bug at hand. There are probably better examples around there. This hasn't gone out of control yet because not many things actually make use of the xorg non-monolith provided pkg-config files instead of just blatantly listing "-lXrandr" and the like, and libXrender works around it, but we need to fix this regardless, and I bet some other beasts are lurking in there (it's hard to just see them, because the problem is with Requires{,.private} chains, not direct ones). The fix is to make Requires.private be recursed into only when asking for --cflags and the like, upstream bug covers the specifics. Fedora is currently using a patch that makes it not be considered at all, but that breaks other corner cases as explained in the referenced URL (in URL field) and especially the links I posted there as an additional comment. This bug is mainly for the purpose of reminding me to deal with it, as I want to see for a few days/week if upstream will finally react and comment on this this time around before testing and including the latest patches.
Dropping links I came across browsing upstream empathy bugs that might be of interest: http://bugs.freedesktop.org/show_bug.cgi?id=15199 http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/953
Didn't remember I had filed this bug. Nowadays we have trouble from this for glib[+sysprof] https://github.com/pkgconf/pkgconf/issues/126
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7985685a5519b29d714a3037d7d4a8d3af02a0ca commit 7985685a5519b29d714a3037d7d4a8d3af02a0ca Author: David Seifert <soap@gentoo.org> AuthorDate: 2021-08-04 19:42:37 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2021-08-04 19:42:37 +0000 profiles: last-rite dev-util/pkgconfig Closes: https://github.com/gentoo/gentoo/pull/21885 Bug: https://bugs.gentoo.org/245228 Bug: https://bugs.gentoo.org/632124 Bug: https://bugs.gentoo.org/691268 Bug: https://bugs.gentoo.org/767853 Signed-off-by: David Seifert <soap@gentoo.org> profiles/package.mask | 7 +++++++ 1 file changed, 7 insertions(+)
This is also relevant to pkgconf, as far as I know. While it has a way to avoid this, it isn't enabled in pkg-config mode or something
It looks like this behaves correctly with pkgconf-1.8.0. pkg-config --exists is looking for Requires dependencies, and ignoring Requires.private. Let me know if I'm missing something here: > % pwd > /usr/lib64/pkgconfig > > % grep -RF renderproto > xrender.pc:Requires: xproto renderproto >= 0.9 x11 > xorg-server.pc:Requires.private: xproto >= 7.0.31 randrproto >= 1.6.0 renderproto >= 0.11 xextproto >= 7.2.99.901 inputproto >= 2.3 kbproto >= 1.0.3 fontsproto >= 2.1.3 pixman-1 >= 0.27.2 videoproto scrnsaverproto >= 1.1 resourceproto >= 1.2.0 xf86driproto >= 2.1.0 glproto >= 1.4.17 dri >= 7.8.0 dri2proto >= 2.8 dri3proto >= 1.2 presentproto >= 1.1 xineramaproto pciaccess >= 0.12.901 > > % sudo rm /usr/share/pkgconfig/renderproto.pc > > % pkg-config --exists xrender; echo $? > 1 > > % pkg-config --exists xorg-server; echo $? > 0
(In reply to Mart Raudsepp from comment #0) > At least since pkgconfig-0.22 packages listed in Requires.private are > ensured to be present during pkg-config --exists checks, this inherently > also means PKG_CHECK_MODULES m4 macro. The PKG_CHECK_MODULES m4 macro calls pkg-config 3 times: 1. pkg-config --exists MODULE 2. pkg-config --cflags MODULE 3. pkg-config --libs MODULE With pkgconf 1.8.0, the first and third invocation succeed if Requires.private dependencies are not installed. The second invocation fails because `pkg-config --cflags` requires that all dependencies listed in Requires.private be installed.
