| Message ID | 20260530081837.2192126-1-f_l_k@t-online.de |
|---|---|
| State | Under Review |
| Headers | show |
| Series | [meta-oe] gd: fix build with gcc 16 | expand |
Hi, On 5/30/26 10:18, Markus Volk via lists.openembedded.org wrote: > https://github.com/libgd/libgd/issues/990 > > Signed-off-by: Markus Volk <f_l_k@t-online.de> > --- > .../0001-gd.c-fix-maybe_uninitialized.patch | 26 +++++++++++++++++++ > meta-oe/recipes-support/gd/gd_2.3.3.bb | 1 + > 2 files changed, 27 insertions(+) > create mode 100644 meta-oe/recipes-support/gd/gd/0001-gd.c-fix-maybe_uninitialized.patch > > diff --git a/meta-oe/recipes-support/gd/gd/0001-gd.c-fix-maybe_uninitialized.patch b/meta-oe/recipes-support/gd/gd/0001-gd.c-fix-maybe_uninitialized.patch > new file mode 100644 > index 0000000000..9fd51da68f > --- /dev/null > +++ b/meta-oe/recipes-support/gd/gd/0001-gd.c-fix-maybe_uninitialized.patch > @@ -0,0 +1,26 @@ > +From 1bb2911c02193d32f1458b771c485980fd100010 Mon Sep 17 00:00:00 2001 > +From: Markus Volk <f_l_k@t-online.de> > +Date: Sat, 30 May 2026 10:12:26 +0200 > +Subject: [PATCH] gd.c: fix maybe_uninitialized > + > +Upstream-Status: Pending [https://github.com/libgd/libgd/issues/990] > I really hate that warning, a guessing compiler :( Anyway, the upstream status is not pending, but not excepted / closed. With kind regards, Jeroen
Sorry, > Anyway, the upstream status is not pending, > but not excepted / closed. > Accepted obviously..
However, 'Rejected' seemed like a somewhat inappropriate upstream status as well, since this was just an issue, not a pull request, and the solution was even suggested by the maintainer himself. He just hasn't been able to reproduce the problem yet, so more feedback is needed to convince him that people have an issue here. Who's to blame is a different story :) That's why I chose 'Pending', but if necessary I can of course make this 'Rejected'.
Hi Markus, On 6/3/26 10:35, Markus Volk wrote: > However, 'Rejected' seemed like a somewhat inappropriate upstream > status as well, since this was just an issue, > not a pull request, and the solution was even suggested by the > maintainer himself. He just hasn't been able > to reproduce the problem yet, so more feedback is needed to convince > him that people have an issue here. > > Who's to blame is a different story :) > > That's why I chose 'Pending', but if necessary I can of course make > this 'Rejected'. Don't get me wrong btw, I don't really mind the patch, I mind the warning. Since it flags there "might" be an issue there. Maintainer looks at it, euuh no, there is now issue -> closes issue. But that warnings is still there, so OE gets patched and marked as pending, that is asking for that patch to pending for a long time. That makes the "pending" state a bit doubtful. And I agree with you that rejected is at the opposite end. As said, I don't really mind, I just don't like a "possible" issue taking time of several people. For what it is worth btw, char a[1000] = {0}; will initialize the whole array. I doubt it matters in this case, but it likely does cost you runtime performance, just to get rid of a likely useless warning. Regards, Jeroen
yeah, I think if upstream is not taking this patch lets disable the warning temporarily and see what lands as right fix. On Wed, Jun 3, 2026 at 5:00 AM Jeroen Hofstee via lists.openembedded.org <jeroen=myspectrum.nl@lists.openembedded.org> wrote: > Hi Markus, > > On 6/3/26 10:35, Markus Volk wrote: > > However, 'Rejected' seemed like a somewhat inappropriate upstream status > as well, since this was just an issue, > not a pull request, and the solution was even suggested by the maintainer > himself. He just hasn't been able > to reproduce the problem yet, so more feedback is needed to convince him > that people have an issue here. > > Who's to blame is a different story :) > > That's why I chose 'Pending', but if necessary I can of course make this > 'Rejected'. > > > Don't get me wrong btw, I don't really mind the patch, I mind the warning. > > Since it flags there "might" be an issue there. > Maintainer looks at it, euuh no, there is now issue -> closes issue. > But that warnings is still there, so OE gets patched and marked as pending, > that is asking for that patch to pending for a long time. > > That makes the "pending" state a bit doubtful. And I agree with you that > rejected is at the opposite end. > > As said, I don't really mind, I just don't like a "possible" issue taking > time > of several people. > > For what it is worth btw, char a[1000] = {0}; will initialize the whole > array. > > I doubt it matters in this case, but it likely does cost you runtime > performance, > just to get rid of a likely useless warning. > > Regards, > Jeroen > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#127380): > https://lists.openembedded.org/g/openembedded-devel/message/127380 > Mute This Topic: https://lists.openembedded.org/mt/119559653/1997914 > Group Owner: openembedded-devel+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [ > raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
Am So, 7. Jun 2026 um 14:04:24 -07:00:00 schrieb Khem Raj <raj.khem@gmail.com>: > yeah, I think if upstream is not taking this patch lets disable the > warning temporarily and see what lands as right fix. This would just disable the warning without patching the code: CFLAGS += "-Wno-error=maybe-uninitialized" We already have this added for DEBUG_OPTIMIZATION: DEBUG_OPTIMIZATION:append = " -Wno-error=maybe-uninitialized" I assume it makes sense to keep this line as well since that CFLAGS entry is only meant to be temporary ?
yes lets disable it via cmdline. On Tue, Jun 9, 2026 at 7:57 AM Markus Volk <f_l_k@t-online.de> wrote: > Am So, 7. Jun 2026 um 14:04:24 -07:00:00 schrieb Khem Raj < > raj.khem@gmail.com>: > > yeah, I think if upstream is not taking this patch lets disable the > warning temporarily and see what lands as right fix. > > > This would just disable the warning without patching the code: > CFLAGS += "-Wno-error=maybe-uninitialized" > > > We already have this added for DEBUG_OPTIMIZATION: > DEBUG_OPTIMIZATION:append = " -Wno-error=maybe-uninitialized" > > I assume it makes sense to keep this line as well since that CFLAGS entry > is only meant to be temporary ? > >
diff --git a/meta-oe/recipes-support/gd/gd/0001-gd.c-fix-maybe_uninitialized.patch b/meta-oe/recipes-support/gd/gd/0001-gd.c-fix-maybe_uninitialized.patch new file mode 100644 index 0000000000..9fd51da68f --- /dev/null +++ b/meta-oe/recipes-support/gd/gd/0001-gd.c-fix-maybe_uninitialized.patch @@ -0,0 +1,26 @@ +From 1bb2911c02193d32f1458b771c485980fd100010 Mon Sep 17 00:00:00 2001 +From: Markus Volk <f_l_k@t-online.de> +Date: Sat, 30 May 2026 10:12:26 +0200 +Subject: [PATCH] gd.c: fix maybe_uninitialized + +Upstream-Status: Pending [https://github.com/libgd/libgd/issues/990] +--- + src/gd.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/gd.c b/src/gd.c +index fd8d1aa2..6ffdd41f 100644 +--- a/src/gd.c ++++ b/src/gd.c +@@ -2069,7 +2069,7 @@ BGD_DECLARE(void) gdImageArc (gdImagePtr im, int cx, int cy, int w, int h, int s + BGD_DECLARE(void) gdImageFilledArc (gdImagePtr im, int cx, int cy, int w, int h, int s, int e, + int color, int style) + { +- gdPoint pts[363]; ++ gdPoint pts[363] = {0}; + int i, pti; + int lx = 0, ly = 0; + int fx = 0, fy = 0; +-- +2.54.0 + diff --git a/meta-oe/recipes-support/gd/gd_2.3.3.bb b/meta-oe/recipes-support/gd/gd_2.3.3.bb index 062c4b4a8f..cc78fd8de7 100644 --- a/meta-oe/recipes-support/gd/gd_2.3.3.bb +++ b/meta-oe/recipes-support/gd/gd_2.3.3.bb @@ -16,6 +16,7 @@ DEPENDS = "freetype libpng jpeg zlib tiff" SRC_URI = "git://github.com/libgd/libgd.git;nobranch=1;protocol=https \ file://0001-Fix-deprecared-function-prototypes.patch \ file://Fix-ftype-missing-const.patch \ + file://0001-gd.c-fix-maybe_uninitialized.patch \ " SRCREV = "b5319a41286107b53daa0e08e402aa1819764bdc"
https://github.com/libgd/libgd/issues/990 Signed-off-by: Markus Volk <f_l_k@t-online.de> --- .../0001-gd.c-fix-maybe_uninitialized.patch | 26 +++++++++++++++++++ meta-oe/recipes-support/gd/gd_2.3.3.bb | 1 + 2 files changed, 27 insertions(+) create mode 100644 meta-oe/recipes-support/gd/gd/0001-gd.c-fix-maybe_uninitialized.patch