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 --------------------
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 56285@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 56285
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch