GNU bug report logs - #55541
[PATCH] gnu: Add azpainter.

Previous Next

Package: guix-patches;

Reported by: Tobias Kortkamp <tobias.kortkamp <at> gmail.com>

Date: Fri, 20 May 2022 14:17:01 UTC

Severity: normal

Tags: patch

Done: zimoun <zimon.toutoune <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #13 received at 55541-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Tobias Kortkamp <tobias.kortkamp <at> gmail.com>
Cc: 55541-done <at> debbugs.gnu.org
Subject: Re: bug#55541: [PATCH] gnu: Add azpainter.
Date: Fri, 24 Jun 2022 22:56:06 +0200
Hi Tobias,

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

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

Applied, thanks!

Maxime Devos <maximedevos <at> 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’.




This bug report was last modified 2 years and 331 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.