Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

On 2019-08-08 22:23, Ben Hutchings wrote:
> On Thu, 2019-08-08 at 22:38 +0200, Aurelien Jarno wrote:
> [...]
> > 1) Build a 64-bit compiler targeting the 32-bit corresponding
> >    architecture and install it in the 32-bit chroot with the other
> >    64-bit dependencies. This is still a kind of cross-compiler, but the
> >    rest of the build is unchanged and the testsuite can be run. I guess
> >    it *might* be something acceptable. release-team, could you please
> >    confirm?
> >    
> >    In the past it would have been enough to "just" do that for GCC, but
> >    nowadays, it will also be needed for rustc, clang and many more. The
> >    clang case is interesting as it is already a cross-compiler
> >    supporting all the architectures, but it default to the native
> >    target. I wonder if we should make mandatory the "-target" option,
> >    just like we do not call "gcc" anymore but instead "$(triplet)-gcc".
> >    Alternatively instead of creating new packages, we might just want
> >    to use the corresponding multiarch 64-bit package and use a wrapper
> >    to change the native target, ie passing -m32 to gcc or -target to
> >    clang.
> [...]
> > Any comments, ideas, or help here?
> [...]
> 
> 1a. Require 32-bit build environments to be multiarch with the
>     related 64-bit architecture also enabled.

Indeed, but that looks like the first step. From there do you think
a) the package is responsible for build-depending on the 64-bit
   toolchain and calling it with the right option to generate 32-bit
   binaries?
or
b) the build environment should be already configured to make the
   64-bit toolchain available transparently

I had option b) in mind, but option a) looks way easier to implement on
the infrastructure side, although a bit less on the packaging side. It
can also be a first step towards b). In that case we should also make
sure that using a 64-bit compiler doesn't switch the package build
system to a cross-compilation mode, where notably the testsuite is
disabled.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[email protected]                 http://www.aurel32.net

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAl1MoiEACgkQE4jA+Jno
M2thZw/+MR/e+Idw4AR+7irYy7b3WbbwADU74DPBkXpnE6ZLbF8euBHHEdZWEMnk
zayPcvcRqkdx/YAL3/7Oh2mv7RPvg01QOnX4ktQ6MWuBQnSGi2d1yMtCwDKh8sHB
Co/ZgRMB68iQLP8RGPbo/oijJkehNUlD7gmo3vH8opUpcsP/ZiELH6todDG+4ZNQ
903wgHjwgDfk1s99mELfX0y75UZskOXv2iaq+MlYqzFe02i1Qi3kTjwrANBfS2c6
hzSviWUHRUnPvKyeIXR3hWXO0G5VHgfdEqZyW50lW2DlL1oFeh+CUpwiU/dLKD6H
GyE0WCYU0YYDnjKk41dKzYo5ih2SKTcVBk+uTsf/Tmbdut/QrrYv5k1g7ZKXmkV1
sl6pY+mWPgLrjFEG+f5yNyX0+6ZTzETuimKQ94UFmK4eCxVHfN7eqy56iPrQ95LD
kl2NU8lFG1I31a7ZRbgiG9Q5rOCBQx7v//sirzs0/wiyM/YJiemWbl4bcvmYuZgq
F9fSkrgXSyp1Sa3hzUyO6UI+NkhA4r5NgGoBepP9OQ72+vbNvIyReukuV8QiFmV3
I8iqSsMlP0pXyusLqFU/EAl8XoHOcup3ofp6fluO+N3bBzMw9BK1v3uBQ/qogKwY
nllM0d7fCuycLwTaoogMMjmeRFpbLpTbSI3Atbv9hZAML1c9VbY=
=k8UV
-----END PGP SIGNATURE-----