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

[Ludovic Courtès]

Hi Tobias,

Tobias Kortkamp <tobias.kortkamp@gmail.com> skribis:

> * gnu/packages/graphics.scm (azpainter): New variable.

Applied, thanks!

Maxime Devos <maximedevos@telenet.be> skribis:

> 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.

These are all good points and I appreciate that you did such a thorough
review (audit?) of the package!

That said, I think it’s a bit too much to ask of a downstream packager
or user to address these issues.  As I see it, these issues should be
reported upstream and addressed upstream.

I hope that makes sense!

Thanks,
Ludo’.