From what I remember from discussion in #4719 @theuni didn't agree with this change because it breaks compatibility with OSX 10.6.

Can you do this in a way that does not break that compatibility, for example one that conditionally uses the included pkg.m4 in case it is missing in the system?

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4963_897e18f67cdb94853645a0021323bdc8831a70e2/ for binaries and test log.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

Let's wait here and make an official decision for what's supported for build/run and what's not. I have some change I've been working on that will allow us to target any SDK, so for that we'll want to evaluate a reasonable minimum for both. Until then, I'd rather not knowingly break anything that the docs say we support.

But isn't it possible to just use pkg.m4 when a system copy cannot be found (as the comment already says, but doesn't seem to be the case in practice according to discussion in #4719)?

I really could've sworn that I tested and verified this behavior when it was added, but it's not working that way at the moment, so I suppose I was wrong on that. @randy-waterhouse Is there any m4 magic that could help us with that?

I had a quick look at using some m4 to use our pkg.m4 only if the system copy doesn't exist but it will be messy.

My take on it is pkg-config is a hard build dependency like autoconf, automake, g++ or clang, etc. As such, it is a hard requirement that pkg-config needs to be installed correctly for a user to build bitcoin, i.e., we can't be expected to have fixes to work around for poor installs of these other build deps either.

I see nothing special about OSX 10.6 versus 10.7, 8 and 9 that would make the pkg-config install behave functionally any different. Therefore most likely it is that around that time linux package installers for Darwin switched from primarily using Fink or Macports to Homebrew, and Fink uses different locations for base and build system installing. A mixture of base packages installed by Fink and Ports and Brew on the same system is a user choice/error.

Maybe we could put the fix in as is and try to help the few users that might be affected to repair their old OSX 10.6 systems properly? I can hang-out on #bitcoin-build for support if necessary.

To me that sounds like extra work without clear gain.

There's no gain to be had here. I'm tired of arguing it and I don't want to start all over again. Please just drop this. We'll nuke it when we drop support for 10.6.

@randy-waterhouse: feel free to revive this now, since #5684 has been merged.