Hello perl people and cross people, I've been looking into ways to cross compile perl for a while now. Unfortunately perl looks quite resistant. I tried to improve its ./Configure to use less compile&run tests (#775940). The issue here seems that there still is disagreement on whether ./Configure is source. The upstream claim is that it is, but upstream also insists[1] that for improving cross compilation, it should be regenerated, which is kinda schizophrenic. To me it looks like we're not getting anywhere if we try to fix ./Configure and this is sad. While the license does allow derivative works of it, that freedom (DFSG #3) is practically lost here as patches to it do not get applied. I basically see two alternatives. Either we somehow record ./Configure runs or we replace it entirely. The first approach has been mostly implemented by Niko Tyni and he keeps maintaining it. As far as I understand, the resulting config.sh is recorded from native builds and stored in the source package below debian/cross/$DEB_HOST_ARCH. Judging from the changelog, it seems that maintaining them keeps incurring work on Niko, which is sad. It also lacks a number of non-ports architectures and essentially any architecture that is about to be bootstrapped. Still those recorded config.sh are quite valuable in understanding what perl actually needs to know. Thus I tried to reverse engineer an approximation of ./Configure that derives its output from dpkg-architecture and dpkg-buildflags. If it works well, it can do arbitrary architectures (even those where we do not have a config.sh). Unfortunately, it doesn't work well. You can find my genconfig.sh attached and for the current unstable release it seems to guess the output right for most settings except the following: * alignbytes * castflags * ccsymbols * cf_time (probably useless) * cppccsymbols * cppsymbols * d_casti32 * d_castneg * doublenanbytes * gccversion (probably useless) * i_quadmath (probably defined for any-x86) * libc * libpth (strange variations) * libspath (strange variations) * longdblinfbytes * longdblkind * longdblmantbits * longdblnanbytes * longdblsize * myarchname * myuname * need_va_copy * osvers (looks arbitrary) * plibpth (strange variations) * sPRIEUldbl * sPRIFUldbl * sPRIGUldbl * sPRIeldbl * sPRIfldbl * sPRIgldbl * sSCNfldbl * selectminbits * sig_count * sig_name * sig_name_init * sig_num * sig_num_init * sig_size I'm not sure whether this approach can load to something that actually works, but I am sharing it here for discussion. The other approach is essentially implemented already: https://arsv.github.io/perl-cross/ This looks well-maintained for quite a while now. I can tell that it won't work out of the box, because it has no clue about multiarch, doesn't know about kfreebsd, hurd or musl and oversimplifies handling of long doubles. Is this worth pursuing? I'd like to add perl to the bootstrap testing performed on jenkins.debian.net. Doing so would presently break mips64r6el, mipsr6el, musl-linux-any, nios2, powerpcel, sh3, sparc, and tilegx and complicate arm64ilp32, hurd-amd64, and kfreebsd-armhf down the road. Thus I'm reluctant to just adding it. Does anyone see a way forward? I hope that it is ok to simply copy this discussion to both lists. If not, I think we should move to only d-cross@l.d.o. Helmut [1] https://rt.perl.org/Public/Bug/Display.html?id=124326
Attachment:
genconfig.sh
Description: Bourne shell script