Following discussions [1,2], this report tracks issue when
cross-compiling the package ’azpainter’, if it would make sense to
cross-compile such package. ;-)
For the record, upstream [3] does not have a clear bug tracker where to
-------------------- Start of forwarded message --------------------
Tobias Kortkamp schreef op vr 20-05-2022 om 13:18 [+0200]:
As-is, this home-grown build system is broken when cross-compiling:
* When cross-compiling, TARGET-gcc needs to be used instead of gcc.
Maybe do (setenv "CC" #$(cc-for-target)) first?
* Likewise, TARGET-pkg-config instead of pkg-config (not 100% sure)
* It tries to run binaries during ./configure. When cross-compiling,
./conftest will always fail (unless using emulation) and hence
always detect ‘little endian’ but this is incorrect when
cross-compiling for big-endian architectures.
(Needs some fixes or work-arounds.) You can test with "guix build
azpainter --target=aarch64-linux-gnu" or such.
Also, some other problems. From mlk_studio.c
int mFILEreadBE32(FILE *fp,void *buf)
if(fread(v, 1, 4, fp) < 4)
*((uint32_t *)buf) = ((uint32_t)v[0] << 24) | (v[1] <<
16) | (v[2] << 8) | v[3];
looks like a potential strict-aliasing violation to me, resulting in
undefined behaviour -- what if buf is a pointer to an array of, say,
doubles? Also a potential alignment problem, though maybe it's only
called for sufficiently aligned 'buf'. The strict-aliasing problem
can be worked around with -fno-strict-aliasing or maybe just -fno-ipa-
strict-aliasing , though I don't know if that's sufficient.
-------------------- End of forwarded message --------------------