Like .so symlinks and .h header files, the .pc files are not be shipped in libXXX debian packages, but in the accompanying libXXX-dev packages as they are only useful when developing against that library.
Stuff in /usr/local usually supersedes stuff in /usr, so I'm a bit confused as to why you would install libraries there to have a "a nice custom distro", but then not want to compile against them. Those are the libraries the system will use actually use.
Anyway, man pkg-config claims the base search path:
is libdir/pkgconfig:datadir/pkgconfig where libdir is the libdir for pkg-config and datadir is
the datadir for pkg-config when it was installed.
This implies they are compiled in. I notice it is different on ubuntu than fedora -- the former is long and inclusive, whereas the latter is short and exclusive; on fedora I have to set a $PKG_CONFIG_PATH to include /usr/local.
Since paths in $PKG_CONFIG_PATH are checked first, you could just set:
PKG_CONFIG_PATH=/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
The fact that these are at the end of the built-in paths won't matter; if the check makes it to there without finding anything, there's nothing to be found.
To demonstrate how this works, create a temporary directory /opt/bs/pkg and copy a .pc file from one of the directories in the default path into it -- e.g., alsa.pc. First check;
> pkg-config --libs alsa
-lasound
Now go into /opt/bs/pkg/alsa.pc and change -lasound (it's in the Libs: field) to -foobar. Set $PKG_CONFIG_PATH and try again:
> PKG_CONFIG_PATH=/opt/bs/pkg pkg-config --libs alsa
-foobar
Eureka, $PKG_CONFIG_PATH has overridden the built-in paths...you can delete /opt/bs/pkg, of course.
Best Answer
It’s finding them in
/usr/lib/x86_64-linux-gnu/pkgconfig/gtk+-3.0.pc(assuming you’re onamd64). On Debian,pkg-configalso searches the multi-arch directory for the target, i.e./usr/lib/$(dpkg-architecture -q DEB_TARGET_MULTIARCH)/pkgconfig.