Message ID | 20240429102959.3493324-1-zboszor@gmail.com |
---|---|
State | Accepted, archived |
Commit | 914128f6bd988cde278e087fb9457a0c70c7e5ec |
Headers | show |
Series | cracklib: Modify patch to compile with GCC 14 | expand |
Thanks for fixing this, however I would also suggest to submit this upstream and see if this is acceptable On Mon, Apr 29, 2024 at 3:30 AM Zoltan Boszormenyi via lists.openembedded.org <zboszor=gmail.com@lists.openembedded.org> wrote: > > GCC 14 implicitly turns a warning into a compiler error: > > | ../../git/src/lib/packlib.c: In function ‘PWClose’: > | ../../git/src/lib/packlib.c:554:40: error: passing argument 1 of ‘HwmsHostToBigEndian’ from incompatible pointer type [-Wincompatible-pointer-types] > | 554 | HwmsHostToBigEndian(tmp_pwp.hwms, sizeof(tmp_pwp.hwms), en_is32); > | | ~~~~~~~^~~~~ > | | | > | | uint32_t * {aka unsigned int *} > | ../../git/src/lib/packlib.c:142:27: note: expected ‘char *’ but argument is of type ‘uint32_t *’ {aka ‘unsigned int *’} > | 142 | HwmsHostToBigEndian(char *pHwms, int nLen,int nBitType) > | | ~~~~~~^~~~~ > > Add the cast to (char *) to silence it. > > Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> > --- > ...0001-packlib.c-support-dictionary-byte-order-dependent.patch | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch b/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch > index 20572b55c4..35229ae890 100644 > --- a/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch > +++ b/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch > @@ -303,7 +303,7 @@ index 9396e1d..d0bb181 100644 > + PWDICT tmp_pwp; > + > + memcpy(&tmp_pwp, pwp, sizeof(PWDICT)); > -+ HwmsHostToBigEndian(tmp_pwp.hwms, sizeof(tmp_pwp.hwms), en_is32); > ++ HwmsHostToBigEndian((char *)tmp_pwp.hwms, sizeof(tmp_pwp.hwms), en_is32); > + fwrite(tmp_pwp.hwms, 1, sizeof(tmp_pwp.hwms), pwp->wfp); > } > } > -- > 2.44.0 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#198734): https://lists.openembedded.org/g/openembedded-core/message/198734 > Mute This Topic: https://lists.openembedded.org/mt/105797819/1997914 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Mon, 2024-04-29 at 08:03 -0700, Khem Raj via lists.openembedded.org wrote: > Thanks for fixing this, however I would also suggest to submit this > upstream and see if this is acceptable The patch this is changing one of our patches but I can't tell if the code being patched by the patch is "ours" or upstream. Cheers, Richard
On Mon, Apr 29, 2024 at 6:37 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Mon, 2024-04-29 at 08:03 -0700, Khem Raj via lists.openembedded.org > wrote: > > Thanks for fixing this, however I would also suggest to submit this > > upstream and see if this is acceptable > > The patch this is changing one of our patches but I can't tell if the > code being patched by the patch is "ours" or upstream. its the behavior coming from our own patch so in that case perhaps no need to bother upstream. However, the patch itself is also submitted upstream which has some feedback to reimplement the logic, so perhaps for now we are ok to accept it locally. > > Cheers, > > Richard
2024. 04. 29. 20:08 keltezéssel, Khem Raj írta: > On Mon, Apr 29, 2024 at 6:37 PM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: >> On Mon, 2024-04-29 at 08:03 -0700, Khem Raj via lists.openembedded.org >> wrote: >>> Thanks for fixing this, however I would also suggest to submit this >>> upstream and see if this is acceptable >> The patch this is changing one of our patches but I can't tell if the >> code being patched by the patch is "ours" or upstream. > its the behavior coming from our own patch so in that case perhaps > no need to bother upstream. However, the patch itself is also submitted upstream > which has some feedback to reimplement the logic, so perhaps for now > we are ok to accept it locally. Thank you. FYI, I have upgraded my laptop to Fedora 40 that has GCC 14. I tried building pieces of Yocto 4.3 and 5.0, and observed some other failures. One of them was vala-native. Upgrading the vala recipe to 0.56.17 fixes the build error, but it also needs newer dependencies. First gobject-introspection 1.80.x, which needs glib 2.80.0. In turn, glib 2.80.0 wants to use gobject-introspection by default, which can be disabled. It is the current state of affairs, as older glib versions do not use gobject-introspection. The other way is to introduce a glib-2.0-initial recipe (built with -Dintrospection=disabled) and add glib-2.0-initial as a build dependency to gobject-introspection, and add gobject-introspection to the glib-2.0 recipe. What would be the recommended way if I wanted to post my GCC 14 build fix patches? Thanks in advance, Zoltán Böszörményi
2024. 04. 30. 10:17 keltezéssel, Zoltan Boszormenyi via lists.openembedded.org írta: > 2024. 04. 29. 20:08 keltezéssel, Khem Raj írta: >> On Mon, Apr 29, 2024 at 6:37 PM Richard Purdie >> <richard.purdie@linuxfoundation.org> wrote: >>> On Mon, 2024-04-29 at 08:03 -0700, Khem Raj via lists.openembedded.org >>> wrote: >>>> Thanks for fixing this, however I would also suggest to submit this >>>> upstream and see if this is acceptable >>> The patch this is changing one of our patches but I can't tell if the >>> code being patched by the patch is "ours" or upstream. >> its the behavior coming from our own patch so in that case perhaps >> no need to bother upstream. However, the patch itself is also submitted upstream >> which has some feedback to reimplement the logic, so perhaps for now >> we are ok to accept it locally. > > Thank you. > > FYI, I have upgraded my laptop to Fedora 40 that has GCC 14. > I tried building pieces of Yocto 4.3 and 5.0, and observed > some other failures. > > One of them was vala-native. Upgrading the vala recipe to > 0.56.17 fixes the build error, but it also needs newer dependencies. > > First gobject-introspection 1.80.x, which needs glib 2.80.0. > > In turn, glib 2.80.0 wants to use gobject-introspection by default, > which can be disabled. It is the current state of affairs, as older > glib versions do not use gobject-introspection. > > The other way is to introduce a glib-2.0-initial recipe (built with > -Dintrospection=disabled) and add glib-2.0-initial as a build > dependency to gobject-introspection, and add gobject-introspection > to the glib-2.0 recipe. > > What would be the recommended way if I wanted to post my > GCC 14 build fix patches? Nevermind, I can see that master-next has this change already. > > Thanks in advance, > Zoltán Böszörményi > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#198754): https://lists.openembedded.org/g/openembedded-core/message/198754 > Mute This Topic: https://lists.openembedded.org/mt/105797819/3617728 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [zboszor@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
diff --git a/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch b/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch index 20572b55c4..35229ae890 100644 --- a/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch +++ b/meta/recipes-extended/cracklib/cracklib/0001-packlib.c-support-dictionary-byte-order-dependent.patch @@ -303,7 +303,7 @@ index 9396e1d..d0bb181 100644 + PWDICT tmp_pwp; + + memcpy(&tmp_pwp, pwp, sizeof(PWDICT)); -+ HwmsHostToBigEndian(tmp_pwp.hwms, sizeof(tmp_pwp.hwms), en_is32); ++ HwmsHostToBigEndian((char *)tmp_pwp.hwms, sizeof(tmp_pwp.hwms), en_is32); + fwrite(tmp_pwp.hwms, 1, sizeof(tmp_pwp.hwms), pwp->wfp); } }
GCC 14 implicitly turns a warning into a compiler error: | ../../git/src/lib/packlib.c: In function ‘PWClose’: | ../../git/src/lib/packlib.c:554:40: error: passing argument 1 of ‘HwmsHostToBigEndian’ from incompatible pointer type [-Wincompatible-pointer-types] | 554 | HwmsHostToBigEndian(tmp_pwp.hwms, sizeof(tmp_pwp.hwms), en_is32); | | ~~~~~~~^~~~~ | | | | | uint32_t * {aka unsigned int *} | ../../git/src/lib/packlib.c:142:27: note: expected ‘char *’ but argument is of type ‘uint32_t *’ {aka ‘unsigned int *’} | 142 | HwmsHostToBigEndian(char *pHwms, int nLen,int nBitType) | | ~~~~~~^~~~~ Add the cast to (char *) to silence it. Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> --- ...0001-packlib.c-support-dictionary-byte-order-dependent.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)