[bug#55541] [PATCH] gnu: Add azpainter.

[Maxime Devos]

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.

signature.asc
Description: This is a digitally signed message part