The recommended way to deal with libraries that might not have working .pc metadata appears to be this: > [Alternatively, you may set the environment variables $1[]_CFLAGS > and $1[]_LIBS to avoid the need to call pkg-config. > See the pkg-config man page for more details.]) and in the development branch of dbus, we've documented EXPAT_CFLAGS and EXPAT_LIBS as the way to avoid relying on pkg-config metadata for archaic or wrongly-installed versions of Expat (which seems to include SuSE's mingw32-expat, Bug #102613). However, in a cross-compilation environment with a pre-configured cross-compiler, it's entirely possible that EXPAT_CFLAGS can legitimately be empty: for example, on Bug #102613, <expat.h> appears to already be on the cross-compiler's default search path, so no extra -I flag should be required. The pkg-config macro ends up doing this: > m4_define([_PKG_CONFIG], > [if test -n "$$1"; then > pkg_cv_[]$1="$$1" > elif test -n "$PKG_CONFIG"; then > ... rely on pkg-config ... This means that if $1 (in this case EXPAT_CFLAGS) is set, but to an empty value, then we require .pc metadata. Perhaps the macro should have this pseudo-patch: m4_define([_PKG_CONFIG], -[if test -n "$$1"; then +[if test -n "${$1+set}"; then pkg_cv_[]$1="$$1" so that the decision is really between set vs. unset, rather than between (set && non-empty) vs. (unset || empty).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pkg-config/pkg-config/issues/8.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.