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
Hi Helmut, Yes, I think short-term generating pkgconf.pc/pkg-config.pc instead of using the in-built ones would be good. Long-term this should be fixed upstream, and the upstream agreed. Yes, it’s not a delta I would like to maintain, but if the upstream implemented this, it would be great :)
Hi Helmut, Yes, I think short-term generating pkgconf.pc/pkg-config.pc instead of using the in-built ones would be good. Long-term this should be fixed upstream, and the upstream agreed. Yes, it’s not a delta I would like to maintain, but if the upstream implemented this, it would be great :)
Hi Andrej, not totally happy with it. Downsides: * pkgconf_builtin_pkg_get is a C-API function. It continues to exist, but it'll now always return NULL. Any user of it, will now break. * pkgconf_builtin_pkg_get also is pretty much unfixable as an API. It returns a "pkgconf_pkg_t *" with undefined lifetime. This was fine earlier as it was returning const data, but once we make this dependent on the personality, it wants to return dynamic data and the only way it can do that now is leak that data, which is bad. There is no reasonable way to fix this API. * The generated pkgconf.pc and pkg-config.pc very much now duplicate the personality files. This violates DRY and may pose future consistency issues. * It also causes lintian to notice multilibs and complain with an error. The thing that lintian complains about was that way earlier it's just that it now notices. You may want to add an override. That said, the patch fixes the output and that's what this bug is a bout, right? I also note that the patch intentionally removes the builtin values such that any future modification makes the patch fail to apply and you notice required updates to the patch. What do you think? Helmut