Prepend brew's pkgconfig to PKG_CONFIG_PATH

[cmb69]

This is another attempt to fix recent macOS x64 configure failures.

---

Note that Version: 20241008.186 is supposed to succeed anyway; the problem is with Version: 20241108.324 only.

[cmb69]

Nope, doesn't help.

[cmb69]

Huh, now have Version: 20241023.237.

[cmb69]

Something is messed up there. https://github.com/php/php-src/actions/runs/11758794188/job/32757544083?pr=16741#step:5:492 claims no dependency on ldap/openldap, but that was the message that triggered our investigations. I wonder which curl package we find in the first place.

[hakre]

Interesting. Upstream also yielded a comment that might be related two days ago, at least it is about building PHP/libcurl and the ldap requirement:

I believe the problem is that PHP is wrongly checking the Requires.private line even when it builds with a shared libcurl, which seems incorrect. I don't think this is a problem in curl. The private line lists libs required when building a static build, and then you do need to link with ldap. (by bagder; from in 8.11.0: Requires.private ldap issue)

And later on OP (Thom1b) comments:

Just find the issue: openldap-2.4 has no .pc pkgconfig files, so:

# pkg-config libcurl --exists --print-errors
Package ldap was not found in the pkg-config search path.
Perhaps you should add the directory containing `ldap.pc'
to the PKG_CONFIG_PATH environment variable
Package 'ldap', required by 'libcurl', not found

But returns nothing with openldap-2.6 which has .pc files.

So this is not a curl bug.

[cmb69]

Thank you @hakre! This is certainly related, but I don't understand what's going on there. PHP uses plain PKG_CHECK_MODULES which, to my knowledge, should ignore the private stuff; so why is there a dependency on (open)ldap? Also, what changed recently with the macOS 13 runners? So far everything was good.

It is very hard to figure out what is going on, since Github apparently uses at least three different runner images, and apparently only Version: 20241108.324 causes the configure problems. According the OP's closing comment, I've installed openldap (maybe there is an old one around, or just none there, although it shouldn't be involved), and that works, but that build was using Version: 20241023.237. I'm at a loss.

[hakre]

No Intel nor Arm system on my hand to run builds on or systems to test with these github action images.

I also learned I can not even restart that job.

So unfortunately but honestly: .github is flawed here to properly address it; it should be possible to restart the job. especially as its the freaking image. @cmb69 (solved)

[cmb69]

I had restarted the jobs, but again Version: 20241023.237 is used, so I cancelled. :(

[iluuu1994]

@cmb69 ldap was newly added as a private dependency. curl/curl@1d96067 Not sure why our build script thinks they are required, maybe @petk can help?

[cmb69]

This is not the fault of our configuration, since we ever only use PKG_CHECK_MODULES but never PKG_CHECK_MODULES_STATIC. As such, the .private stuff should never get in the way (although it's not necessarily correct what we're doing). Something is messed up with the pkgconfig file of cURL. Let's see.

[iluuu1994]

I also checked for pkg-config (I had to trigger it about a dozen times before finally getting the right image to run, so I'll spare you the joy). https://github.com/iluuu1994/php-src/actions/runs/11781754955/job/32815254937 From what I understand, this does look correct.

Oh, I just realized the curl version pkg-config reports is not the one installed via brew...

[iluuu1994]

Here's another try. https://github.com/iluuu1994/php-src/actions/runs/11781877622/job/32815654207

Searching for 'libcurl' private requirement 'ldap'
Looking for package 'ldap'
Looking for package 'ldap-uninstalled'

it does explicitly say "private requirement" here. I don't understand why it says:

Unknown keyword 'Libs.private'

But it says that in the successful build as well.

[cmb69]

It seems that Requires.private is always checked by pkg-config (even when requesting public stuff only); so there needs to be ldap.pc available. However, Homebrew likely ships openldap.pc, so bad luck. Looks like a generic Homebrew issue. We could likely work-around using sed.

Not relevant for us, but still wrong is to set Libs.private flags which are covered by Requires.private. cURL issue.

PS: ldap.pc is the canonical name from OpenLDAP. I would check, but apparently you cannot download a package manually.

[petk]

It seems that Homebrew should use the pkgconf instead of the pkg-config:
Homebrew/homebrew-core#194885

Cflags.private aren't supported there:
https://gitlab.freedesktop.org/pkg-config/pkg-config/-/merge_requests/13

Perhaps something related to this.

[cmb69]

Ah, indeed. While I still don't think that Cflags.private is involved here, there might be different behavior regarding Requires.private. The latest uconfig checks for Requires.private even if only --libs is requested, while pkgconf 1.8.1 would not. I don't know how pgk-config or new versions of pkgconf handle this.

[cmb69]

Okay, latest test used Version: 20241108.324, and since I had added brew reinstall openldap, that is no longer an issue, but now it fails because mit-krb5-gssapi is not available. From looking at curl/curl#15507 (comment), that explains the problem, assuming that pkg-config 0.29.2 (which is used on these images) would always check for Requires.private. Note that cURL 8.11.0 added quite some packages to Requires.private, while cURL 8.10.1 only had these as Libs.private.

[cmb69]

Tried to install pkgconf, but now pgk-config won't work; likely the symlink is missing yet. I wouldn't know where to put it.

[cmb69]

I've managed to use pkgconf as drop-in replacement for pkg-config. But now we have https://github.com/php/php-src/actions/runs/11820495789/job/32932931483?pr=16741. So pkg-config --libs libcurl ignores Requires.private, but pkg-config --cflags libcurl not (pkgconf 2.3.0; same with pkgconf 1.8.1). That seems to be broken.

Anyhow, given that the GH November images appear to be used more often, we need to do something. We might wait on curl/curl#15573 to be rolled out (which probably only cures the symptons, and might not even work). Install further packages (if they're even available). Or maybe hack along.

[cmb69]

MACOS_ARM64_DEBUG_NTS succeeded; our first successful build with libcurl 8.11.0 \o/

[cmb69]

Closing in favor of PR #16783.