Package: pkgconf Version: 1.8.1-1 User: debian-cr...@lists.debian.org Usertags: ftcbfs Control: affects -1 + src:ruby-cairo X-Debbugs-Cc: debian-cr...@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
