PKG_CONFIG_PATH is never changed. i fixed the issue for me by applying the attached patch for pkgconfig. Reproducible: Always Steps to Reproduce: 1. emerge pkgconfig 2. try to use pkgconfig if there's a newer version of some package installed in /usr/local (PKG_CONFIG_PATH points there) 3. things get messed up, since pkgconfig finds things in /usr/local Actual Results: building our own software outside prefix dails, because it detects, that pkgconfig reports a package version lower than the one detected by another script. (because there are different versions of the same package in the base system (gentoo linux in this case) and the prefix. Expected Results: detect the package installed in prefix.
uhm, sorry - in the steps to repo 2. i meant that in the outside system an older version of the package is installed. inside prefix is the newer one.
i also tried cutting out the /usr/local bits inside the 99pkgconfig env.d, but it gave me parse errors on merging.... :(
Created attachment 144191 [details, diff] the proposed patch for pkgconfig
Eventually we should explicitly _set_ instead of _extend_ PKG_CONFIG_PATH to "$EPREFIX/usr/$(get_libdir)/pkgconfig:/usr/lib/pkgconfig" Uhm, how to know the libdir in /usr ? How does pkgconfig work with multilib ?
is it really necessary to include the host pkgs? I'm affraid yes, and then we might end up doing something like: (pegasus:src/backends/monet5) fabian% strings /usr/bin/pkg-config | grep pkgconfig http://www.freedesktop.org/software/pkgconfig/ atleast-pkgconfig-version /usr/lib64/pkgconfig:/usr/share/pkgconfig where the last line is the host-specific pkgconfig built in path.
on a second thought, you probably don't want to find host provided packages using pkgconfig. So we should set the pkgconfig search path to prefix only. Comments anyone?
+1. i think so too. after all, we change the behaviour of the prefix installed pkg-config only, without nuking the system one :)
(In reply to comment #6) > on a second thought, you probably don't want to find host provided packages > using pkgconfig. > > So we should set the pkgconfig search path to prefix only. Comments anyone? We definitely must avoid /usr/local/. But I tend to still keep searching /usr/, although _after_ prefix at all. This allows prefix to _hide_ system-installed libs (by default), but does not completely ignore them if one decides to package.provide them.
Then we're back at start (and you don't get $200) where we have the problem of not knowing what the vendor specific (host) location of pkg-config files is.
*ping* If I read comment #5 correctly, I suffer this bug with X packages! evil
you mean this blocks our profile move? explains the weird behaviour though...
(In reply to comment #11) > you mean this blocks our profile move? > > explains the weird behaviour though... > It explains everything, yes. Is the patch in Comment #3 the target? echo "export PKG_CONFIG_PATH=${EPREFIX}/usr/lib/pkgconfig\${PKG_CONFIG_PATH:+:}\${PKG_CONFIG_PATH}" >> "${T}"/99${PN}. I don't know how to resolve comment #9, but aren't .pc files dictated to be in a standard location? "Uhm, how to know the libdir in /usr ? How does pkgconfig work with multilib ?" Not a concern anymore I think. amd64 is usr/lib/ only, multilib is dead now.
(In reply to comment #12) > Not a concern anymore I think. amd64 is usr/lib/ only, multilib is dead now. The comment is about the host, which /is/ multilib. So it may be lib, lib32, lib64, lib/amd64, lib/sparcv9 and what more was invented on this globe.
(In reply to comment #11) > you mean this blocks our profile move? > > explains the weird behaviour though... > Wow. /me kicks self for not finding this earlier! (confirmed, all my troubles are gone by setting PKG_CONFIG_PATH) Now, we just need to settle on a convention for what to set PKG_CONFIG_PATH equal too. I fear that Comment #3 is not quite correct. Alternatively, I may release some experimental stuff for linux only if a convention cannot be established properly >=)
(In reply to comment #5) > is it really necessary to include the host pkgs? We could indeed try to go *without* the host path, as we (usually) emerge all dependencies into prefix.
I'll try to implement that later tonight. Then we can see what breaks.
(In reply to comment #16) > I'll try to implement that later tonight. Then we can see what breaks. > Nothing breaks (on linux). I did an emerge -e world (some 400 packages) and it completed with PKG_CONFIG_PATH set explicitly to: %% echo $PKG_CONFIG_PATH /home/jolexa/portage/linux-64/usr/lib/pkgconfig
I don't get this any more. pkg-config uses the prefix paths by default, so what does setting PKG_CONFIG_PATH help?
AFAICT, it helps on systems where PKG_CONFIG_PATH is set to something like /usr/local/* in /etc/profile (Interix IIRC), when prefix-bash is started from interix-ksh fex, or when sourcing prefix/etc/profile in interix-shell. Another option could be to explicitly *unset* PKG_CONFIG_PATH in prefix/etc/profile.
I prefer the last option (to unset it)
(In reply to comment #19) > (Interix IIRC) It wasn't on Interix - it was on _my_ Gentoo Linux desktop, where x11-libs/qt-3.3.8-r4 sets PKG_CONFIG_PATH: $ grep PKG_CONFIG_PATH /etc/env.d/* /etc/env.d/45qt3:PKG_CONFIG_PATH=/usr/qt/3/lib/pkgconfig Ohw: x11-libs/qt-3.3.8-r4 pulled in by: dev-db/mysqlnavigator-1.4.2 www-client/opera-9.62 I've not used both for years now...
hmm... i just ran into another problem with cross-prefix... if i have pkg-config installed into one prefix, and want it to find packages from the other prefix... i think the only possible way to go is to set PKG_CONFIG_PATH=${EPREFIX}/usr/lib/pkgconfig:$PKG_CONFIG_PATH. the only question i have left is, wether i should include the existing PKG_CONFIG_PATH value in the new one, or set to EPREFIX exclusively...?
http://overlays.gentoo.org/proj/alt/changeset/35131 (and r35135) Choose to go with: echo "PKG_CONFIG_PATH=${EPREFIX}/usr/lib/pkgconfig:${EPREFIX}/usr/share/pkgconfig" >> "${T}"/99${PN} Note that usr/share/pkgconfig is the correct location for some .pc files as well. (Some people don't know this - I didn't either)
