Re: Cross-compilation problems

[tlaronde%polynum.com@localhost]

Hello,

On Sun, Jul 07, 2019 at 10:35:24AM +0200, Roland Illig wrote:
> Am 06.07.2019 um 15:00 schrieb tlaronde%polynum.com@localhost:
> > There is something wrong with the conditional:
> >
> > .if !empty{USE_CROSS_COMPILE:M[yY][eE][sS]}
> 
> This should be a syntax error. Curiously it is silently accepted by
> bmake and evaluated to true.
> 
> On the other hand, pkglint complains because it has never seen this pattern:
> 
> WARN: cross.mk:2: Invalid condition, unrecognized part:
> "!empty{USE_CROSS_COMPILE:M[yY][eE][sS]}".
> 
> The !empty function call needs round parentheses instead of curly
> braces. Or, alternatively, you can leave out the !empty and write:
> 
> .if ${USE_CROSS_COMPILE:M[yY][eE][sS]}
> 
> I find this much clearer than the !empty.

Thank you, I have corrected this (Taylor R. Campbell has also pointed
it).

Nonetheless, since it was always evaluated to true, the cross-compilation
environment was always there, and it fails for several reasons and
may work only by side effect on a machine with the same size of
word (Taylor R. Campbell wrote me that he was unable to reproduce
with aarch64, but this is earmv7hf which is 32 bits while I'm building
on a amd64 which is 64 bits).

Plus, PKGSRC_USE_FORTIFY is set to true on NetBSD, but as far as I
know, it is machine dependent. Hence with a host (build machine, MATRIX)
on which it is implemented and a target on which it is not, the pkgsrc
framework has to take the two into account. And this is the case for
all the things machine dependent (and if the cross-compilation takes,
wrongly, the headers on the host, if the machine dependent parts are not
used, nobody will see that the compilation is not done with the correct
headers).

The delicate part is indeed the linker part, because it has to link, for
ELF, with the correct 4 objects (crt0.o, crtbegin.o, crtend.o, crti.o),
has to assemble to the correct format and register the correct paths for
dynamically shared libraries, not taking into account a prefix
since the libraries are obviously not in their definitive path on the
host.

If the distinction between MATRIX (the host (OS, machine) one builds on)
and TARGET (the type of (OS, machine) one builds for) is not taken
into account from the beginning, it is, IMHO, almost hopeless.

It is easy to do with new projects (I have done so for KerGIS---a
fork of public domain GRASS---and kerTeX---a TeX distribution---with
my own compilation framework RISK). But with the vast majority of
sources out there, it should be fixed upstream so it is unlikely
to happen soon---and I guess that with emulation and VM people find
it simpler to compile "natively" on a VM.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C