bug#56285: azpainter does not cross-compile

[zimoun]

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.


1: <http://issues.guix.gnu.org/issue/55541>
2: <https://yhetil.org/guix/87r13aifi3.fsf_-_@gnu.org>
3: <https://gitlab.com/azelpg/azpainter>


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]:
> +    (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 --------------------