bazelbuild
pkg-config build broken on clang 15+ and gcc 14+
Background (what is pkg-config?)
pkg-config 0.29.2 (the latest release as of this writing) bundles an ancient version of glib 2.36 (released in August 2013) to workaround the pkg-config/glib circular dependency. It should be noted that pkg-config itself is not well-maintained, with the last major release having been in 2015 and the last point release in 2017, however it remains an important dependency of virtually all build systems as a standardized way to transform dependency names into CFLAGS, LDFLAGS, etc.
Note that glib is not to be confused with GNU libc, often abbreviated to glibc.
The issue
glib 2.36 performed implicit integer conversion for its atomic pointer arithmetic functions, using g(s)size (which is aliased to (u)long) instead of (u)intptr. This was a warning in most compilers for many years but was upgraded to an error with clang 15 and gcc 14. This was addressed in upstream glib in Dec 2022.
Patch and next steps
I've published a patch to the upstream pkg-config mailing list. (GitHub unfortunately is refusing to allow me to attach the .patch file here, despite claiming that .patch is a permitted file extension.) Depending on how quickly the maintainers process it, it may be advisable to bring this patch into rules_foreign_cc in advance of the upstream pkg-config release to unblock builds with newer clang and gcc.
Direct link to the patch (original filename: pkg-config-builtin-glib-int-conversion.patch)
Supply chain integrity / who am I
(In light of the xz thing)
My keybase provides positive proof linking my GitHub account, the domain of my email address, and the PGP key used to sign the patch, the latter of which is also the PGP key I use on GitHub. I am on the same team as @ravenblackx at @dropbox; they are an envoy maintainer and can vouch for me if necessary.
If someone wants to put together a PR to patch the pkg-config build with the provided patch then this is something I'd happily merge.
@jsharpe I added such a patch to my envoyproxy AUR package last month. I don't have the free time to turn this into a rules_foreign_cc PR right this moment, but this patch should be able to be integrated with minimal effort.
It looks like there are other issues with the pkg-config build, using the main branch (e67c45c8db19f13b681fff0d608117308c1bfd4c) on ArchLinux (gcc 14.2.1 and glibc 2.40) I'm getting the following errors during the build:
make[7]: Entering directory '/home/user/.cache/bazel/_bazel_user/713ff1e3f7af5a7d530fffa9d3dbdc1b/sandbox/linux-sandbox/3/execroot/_main/bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_foreign_cc~/toolchains/private/pkgconfig.build_tmpdir/glib/glib/gnulib'
CC libgnulib_la-asnprintf.lo
CC libgnulib_la-printf-args.lo
CC libgnulib_la-printf-parse.lo
CC libgnulib_la-vasnprintf.lo
In file included from /usr/include/stdio.h:970,
from vasnprintf.c:38:
/usr/include/bits/stdio2.h: In function 'sprintf':
/usr/include/bits/stdio2.h:30:10: error: invalid use of '__builtin_va_arg_pack ()'
30 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
31 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
32 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
/usr/include/bits/stdio2.h: In function 'snprintf':
/usr/include/bits/stdio2.h:68:10: error: invalid use of '__builtin_va_arg_pack ()'
68 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
69 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
70 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
In file included from /usr/include/wchar.h:1070,
from printf-args.h:29,
from printf-parse.h:22,
from vasnprintf.c:44:
/usr/include/bits/wchar2.h: In function 'swprintf':
/usr/include/bits/wchar2.h:177:10: error: invalid use of '__builtin_va_arg_pack ()'
177 | return __swprintf_alias (__s, __n, __fmt, __va_arg_pack ());
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[7]: *** [Makefile:997: libgnulib_la-vasnprintf.lo] Error 1
I believe some of the compiler hardening options need to be removed for the pkg-config build to succeed.
The real question is, why are you even using the original pkg-config? Why not use https://github.com/pkgconf/pkgconf? Lots of modern distros ship pkgconf as pkg-config.
