diff mbox series

cracklib: Modify patch to compile with GCC 14

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

Commit Message

Böszörményi Zoltán April 29, 2024, 10:29 a.m. UTC
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(-)

Comments

Khem Raj April 29, 2024, 3:03 p.m. UTC | #1
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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
Richard Purdie April 29, 2024, 4:36 p.m. UTC | #2
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
Khem Raj April 29, 2024, 6:08 p.m. UTC | #3
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
Böszörményi Zoltán April 30, 2024, 8:17 a.m. UTC | #4
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
Böszörményi Zoltán April 30, 2024, 10:06 a.m. UTC | #5
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 mbox series

Patch

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);
  	}
      }