Bug#945057: libnet-dbus-perl FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Hi gregor,

On Tue, Nov 19, 2019 at 06:23:35PM +0100, gregor herrmann wrote:
> On Tue, 19 Nov 2019 06:09:15 +0100, Helmut Grohne wrote:
> 
> > libnet-dbus-perl fails to find the dbus library. It does so using the
> > build architecture pkg-config, but libdbus is only installed for the
> > host architecture. Now I'm unsure how to fix this. 
> 
> Thanks for the bug report, that's an interesting one indeed.

Thank you for looking into it.

> > The common wisdom is
> > to prefix tools with the host architecture triplet. The other wisdom is
> > to pass tools as environment variables. The perl ecosystem seems to
> > follow a different route: Record paths in Config.pm. Unfortunately,
> > Config.pm neither has the triplet nor does it have pkg-config. Bummer.
> 
> So we're looking for something like 'x86_64-linux-gnu' in Config.pm
> (or pass PKG_CONFIG=x86_64-linux-gnu-pkg-config in the environment),
> right?

Yes.

> For the former,
>     % perl -MConfig=config_sh -e 'print config_sh();' | grep x86_64-linux-gnu
> has quite a few results but never x86_64-linux-gnu alone.

That's also what I found.

> Right, but the good news is that I only find 23 packages (of the
> pkg-perl maintained ones) which use pkg-config in
> {Makefile,Build}.PL.

Good.

> Random thought: I wonder if PkgConfig ("a pure perl version of
> pkg-config"), packaged as libpkgconfig-perl, providing
> /usr/bin/ppkg-config, could be a helpful workaround. This would still
> require a changed build dependency and a s/pkg-config/ppkg-config/ in
> {Makefile,Build}.PL [0] but would spare us any path or architecture
> hassles. Maybe :)

I do see why it works practically. If you read /usr/bin/ppkg-confing and
look for the construction of @DEFAULT_SEARCH_PATH, you'll notice that it
checks for the existence of dpkg-architecture and effectively inserts
/usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`/pkgconfig into the
path. While that is what we want here, it does rely on environment
variables again. To see this try:

| $ dpkg-architecture -am68k -c ppkg-config --debug doesnotexist
| dpkg-architecture: warning: specified GNU system type m68k-linux-gnu does not match CC system type x86_64-linux-gnu, try setting a correct CC environment variable
| Can't find doesntexist.pc in any of /usr/local/lib/m68k-linux-gnu/pkgconfig /usr/local/lib/pkgconfig /usr/local/share/pkgconfig /usr/lib/m68k-linux-gnu/pkgconfig /usr/lib/pkgconfig /usr/share/pkgconfig
| use the PKG_CONFIG_PATH environment variable, or
| specify extra search paths via 'search_paths'
| $

So we still don't have our single source of truth here.

The other aspect is that this is very much Debian-specific. Given the
effort it takes to make stuff cross buildable, we want to (and do) share
that work with yocto, ptxdist, buildroot and others as much as possible.
However this transformation doesn't help any other distribution.

Last but not least, this approach breaks an important corner case. It
happens every now and then that we need to build a build tool during a
package build. Such build tools need to be built for the build
architecture (to be runnable) rather than the host architecture, so it
is the task of the build system to explicitly tell which pkgconfig files
are requested for the build and which are requested for the host.

Let me give a positive example of how this could work: meson.  When you
want to use pkg-config in meson, you say "dependency('foo')". And when
you want the build architecture pkg-config, you say "dependency('foo',
native: true)". meson then figures how to call pkg-config. Why am I
telling you this? I think that Makefile.PL should also have some syntax
to tell these apart.

> So, I did my first cross build :) (with cowbuilder and the help of
> https://wiki.debian.org/CrossCompiling ) and it worked with:

Congrats. This sounds like our workflow now mostly "just works"(tm). Let
me know if you run into problems or annoyances.

> libnet-dbus-perl_1.1.0-7_i386.deb

Do note that cross building from amd64 to i386 isn't that enlightening,
because i386 is runnable on amd64. It's nice to be able do so, but it'll
hide a number of possible problems.

Unfortunately, choosing another architecture is a little difficult at
present:
 * All the mipsen are broken, because our gcc maintainer removed mipsen
   support from the toolchain packages and requested that they live in
   special -mipsen packages. Unfortunately crossbuild-essential-* is
   still missing for all mipsen.
 * Most architectures but armel are currently skewed against amd64 due
   to linux ftbfsing on most architectures.

So at the time of this writing, the only reasonable architecture to
cross build for is armel. I hope we get better weather soon.

> [0] or `use PkgConfig …;' programmatically

This would be better, but what we really need to do here is have
PkgConfig.pm derive its default search path from perl's Config.pm.

Helmut