Re: Cross libextutils-pkgconfig-perl (was: Bug#1078010: libnet-z3950-zoom-perl FTCBFS: hard codes the build architecture pkg-config)
Hi Gregor,
On Thu, Aug 29, 2024 at 06:51:35PM +0200, gregor herrmann wrote:
> thanks for taking the time to write this long and detailed email!
Thanks for having taken the time to read such a long email.
> Ack.
> So if ExtUtils::PkgConfig calls /usr/bin/$prefix-pkgconf (with
> $prefix derived from the host architecture), we should be good with
> "Multi-Arch: foreign"?
The implication of Multi-Arch: foreign would be that users have to
additionally depend on pkg-config. Your reply to this proposition was:
> Hm, probably doesn't scale and is prone to errors.
> > That's the other piece of the puzzle, we need to
> > enhance ExtUtils::PkgConfig to somehow pick up the toolchain prefix from
> > the perl Config.pm and we pass
> > -I/usr/lib/i386-linux-gnu/perl/cross-config-5.38.2 to supply a config
> > matching the host architecture. To make matters worse, the toolchain
> > prefix isn't readily available in there. I suppose the best we could do
> > is examine cc and strip "-gcc", but that's a hack at best. Possibly perl
> > needs to record this value or it needs to be passed in some other way.
>
> That's a question for Niko and Dom, if we can get this variable into
> %Config.
Indeed, getting the GNU triplet into the cross Config.pm is something
technically solvable with reasonable effort. A very common way to name
it is $CROSS_COMPILE and when doing so it would have a trailing dash.
For instance CROSS_COMPILE=aarch64-linux-gnu- and using it would work
like ${CROSS_COMPILE}pkg-config such that it also works when the
variable is empty or unset in the native case.
> Yes, but it doesn't look that different to my naïve eyes:
> - All that ExtUtils::PkgConfig does is calling `pkg-config'
> - If we need to change it to call `/usr/bin/$prefix-pkg-config',
> we need the $prefix.
> - If we can't get it from %Config directly, we could abuse
> $Config{cc}, as you write; not elegant but well.
> - I wonder, and maybe this is too trivial to be true, if we couldn't
> just use `dpkg-architecture -qDEB_HOST_GNU_TYPE'?
Ideally, we look at this from two sides simultaneously. Thus far, our
focus has been how to achieve this from a Debian packaging point of
view. The other angle is from an upstream point of view supporting cross
compilation in multiple Linux distributions (such as Yocto,
OpenEmbedded, PtxDist, Alpine, ...). Would you want one mechanism to
communicate the architecture for each distribution or would you want one
mechanism that works for all of them in the same way? Also consider that
people may use Debian for cross compiling their own software without
using dpkg-buildpackage. Long story short, upstream code should not call
into dpkg-architecture nor inspect DEB_HOST_* environment variables.
> I think I'm happy to continue as well.
Yeah. I just do not happen to see the solution that obviously has no
downsides.
I also see a spectrum of modifications to the module implementation that
would change the equation.
A. Reimplement pkg-config entirely in Perl avoiding the need to depend
on pkg-config.
B. Reimplement the search path configuration (i.e. compute a suitable
PKG_CONFIG_LIBDIR depending on the architecture) and pass this
environment variable to pkg-config (not triplet-pkg-config). Beware
though that the variable contains paths containing
DEB_HOST_MULTIARCH and that may differ from DEB_HOST_GNU_TYPE.
C. Stop working with pkg-config and require pkgconf. Then you may
instead call pkgconf --personality=$DEB_HOST_GNU_TYPE ... rather
than using the triplet-prefixed form.
All of these approaches have in common that we avoid requiring
pkg-config:$DEB_HOST_ARCH and can work with pkgconf-bin, which happens
to be M-A:foreign and thus allows our module to also be M-A:foreign.
Do you think any of A/B/C would be upstreamable? Note that all of them
would benefit other cross compiling Linux distributions even though most
of them don't cross Perl extensions to the extend Debian does.
Helmut
Reply to: