Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture
On Mon, Jun 24, 2019 at 10:37:49PM +0200, Helmut Grohne wrote:
> > | implement debhelper support for cross building XS module packages?
> > | effectively make debhelper run 'perl -I /usr/lib/<arch>/perl/cross-config-5.28.1 Makefile.PL' when it detects a cross build
> >
> > which points in the same direction. And I'm sure Niko can add more on
> > this topic than I :)
Yeah, this stuff has been in place for a while now but I haven't really
advertised it anywhere. Sorry about that.
> This is quite precisely the information I was missing thus far. I think
> the major question now is: Who wants to turn this into a debhelper
> patch? The second question is: Why do we need the perl version in that
> part? (Can it be renamed to something without the version?) If there is
> a reason: How do we compute the correct version?
I was hoping to look at the debhelper part of XS module cross builds
during the sprint but ended up converting src:perl debian/rules to dh
instead :) It's certainly on my TODO list but time is scarce nowadays.
Happy if anybody else wants to take over of course.
The way most Perl module builds work is that Makefile.PL (or rather
ExtUtils::MakeMaker) looks up the compiler, linker, install paths etc. in
Config.pm during the build process. The Config.pm module is shipped as
part of the Perl build and is very much version and architecture specific.
For cross builds, the host architecture version of Config.pm needs to
be on the Perl search path before the build architecture version one.
However, we can't just point the build architecture Perl at the host
architecture modules directory because any binary modules (for example
Cwd) in there will not be functional.
So we need to ship a directory with just Config.pm and let the build
architecture perl use the build architecture modules for all other
tasks. Somewhat surprisingly this seemed to work, at least in my limited
tests.
As noted, Config.pm is Perl version specific so it needs to be shipped in
a versioned package and directory. Gregor already showed that computing
the right path is not particularly hard.
One piece that I haven't got in place yet is how the cross build should
pull in the host architecture libperl5.28 package (which contains
/usr/lib/<arch>/perl/cross-config-5.28.1/ with Config.pm). We definitely
don't want build dependencies with hardcoded Perl versions on the
packages. I originally had libperl5.xx Provide perl-cross-config with
the idea that builders could depend on that, but I see I've since moved
that Provides entry to perl (along with others due to #899110). I think
this move was probably wrong and made the perl-cross-config virtual
package useless.
Even with that fixed, adding build dependencies on 'perl-cross-config
<cross>' to all the XS module packages we're targetting with this seems
like a rather arduous undertaking, but doable for bullseye if this is
deemed to be the right approach.
As for the patch in #930980 which just overrides LD and CC: does that
really work as far as installing the generated files in the correct
paths? I'd expect them to end up in the build architecture path instead,
as that comes from the build architecture Config.pm.
Hope I'm making sense, happy to have more eyeballs on this stuff :)
--
Niko
Reply to: