ok, cairo seems to be the only source package with a problem with pkg-config.
Did the other source compiles require those two libs as part of their build process ???
If so, and they used pkg-config in therir configuration process, then it must be configured properly. Easy to check, if you kept build logs for them, those libs should show up as cli inclusions during the link stages. If not, they should be findable in the respective Makefiles.
If thats so, then the focus is more on something to do with cairo than pkg-config.
Have you ran it manually for those two libs. Just to see what kind of output it generates. If it correctly returns the paths to /usr/local, then that would suggest it's not the real problem.
]$ pkg-config --libs --cflags glitz
Does that produce correct output ?
checking for glitz >= 0.4.0... Package glitz was not found in the pkg-config search path.
Assuming pkg-config is correctly configured... a syntax error in the configuration script can generate something like that. Such as, the lib name butting up against one of the switches with out the required white space to seperate them. I've had that occure on a couple of occasions.
Searching back through the config.log file should reveal that, if thats the case.
You could try a couple of symlinks from /usr/bin/pkg-config and /usr/lib/pkg-config down to /usr/local for good measure. But if pkg-config is configured for its' /usr/local install, then that shouldn't be needed.
If the search through cairo doesn't reveal it, and the symlinks don't work, then try setting the env variable.
As far as the /etc/ld.so.config file goes, it will need an entry for /usr/local/lib if it hasn't already got one. But it shouldn't for the standard locations /lib and /usr/lib. But thats really just more for the run-time support.
A none-standard install like /usr/local can be prone to path conflicts though. As thats all it probably is, it will be solved. It's just getting past ./configure thats sometimes problematic.
I would suspect a syntax error in configure though. Or a version conflict. configure can be a bugger of a script to search through(grin). If it had something like ...
pkg-config --libs--cflags glitz instead of
pkg-config --libs --cflags glitz
then that would make configure think that the command failed due to an absent lib. I think it sometimes happens because of quirks associated with the passes that are used to create it.
man pkg-config is worth a look, it seems you can give pkg-config a different "prefix" to test with if you want.
Hope thats all it is
Edit: 14th July 2005:
The only other thing really would be trying the --with-xxxx switches that will likely be available to configure, eith for those libes or pkg-config. Thats a straww grab though.