azpainter does not cross-compile

  • Open
  • quality assurance status badge
Details
One participant
  • zimoun
Owner
unassigned
Submitted by
zimoun
Severity
normal
Z
Z
zimoun wrote on 28 Jun 2022 19:33
(address . bug-guix@gnu.org)
861qv8elr5.fsf@gmail.com
Hi,

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
report the issue.




Cheers,
simon


-------------------- Start of forwarded message --------------------
Subject: [bug#55541] [PATCH] gnu: Add azpainter.
From: Maxime Devos <maximedevos@telenet.be>
Date: Fri, 20 May 2022 18:00:22 +0200

Tobias Kortkamp schreef op vr 20-05-2022 om 13:18 [+0200]:
Toggle quote (11 lines)
> +    (build-system gnu-build-system) ;actually a home grown build system
> +    (arguments
> +     (list #:tests? #f
> +           #:phases
> +           #~(modify-phases %standard-phases
> +               (replace 'configure
> +                 (lambda _
> +                   (invoke "./configure"
> +                           (string-append "--prefix="
> +                                          #$output))))

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)
{
uint8_t v[4];

if(fread(v, 1, 4, fp) < 4)
return 1;
else
{
*((uint32_t *)buf) = ((uint32_t)v[0] << 24) | (v[1] <<
16) | (v[2] << 8) | v[3];
return 0;
}
}

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.

Greetings,
Maxime.
-------------------- End of forwarded message --------------------
?