Bug#1057955: pkgconf: issues wrong pc_path for non-default personality
Package: pkgconf
Version: 1.8.1-1
User: debian-cross@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:ruby-cairo
X-Debbugs-Cc: debian-cross@lists.debian.org
Hi Andrej,
ruby-cairo fails to cross build from source. In essence, it fails to
find cairo.pc. Now ruby-cairo uses ruby-pkg-config to locate cairo.pc,
which does the lookup itself, but before it does it consults pkg-config
for the relevant paths using `$PKG_CONFIG --variable=pc_path
pkg-config`. While it doesn't pass a cross pkg-config by default, this
part is easily fixed. Unfortunately, the cross pkg-config still gives
the native search path. This is due to pkgconf containing builtin
packages for pkgconf and pkg-config see
https://sources.debian.org/src/pkgconf/1.8.1-1/libpkgconf/pkg.c/?hl=946#L990.
While the values of these builtins are personality-dependent in theory,
their implementation is not. Thus they give the wrong answer, which
explains the rest of the build failure.
Example:
$ aarch64-linux-gnu-pkg-config --variable=pc_path pkg-config
/usr/local/lib/x86_64-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
$
Fixing these is a non-trivial affair. I recommend simply deleting the
builtin mechanism and placing a pkgconf.pc and symlink pkg-config.pc
file (which is architecture-dependent) in the pkgconf package (which is
m-a:same). We can easily generate these at package build time.
Do you agree with the analysis? Do you agree with the proposed solution?
Do you see a better approach to solving this? I suspect solving this in
C would amount to rewriting the builtin mechanism in a dynamic way that
can introspect personality properties. I'd like to avoid that.
Helmut
Reply to: