With this update it fails to build on hosts with gcc-14:

| pseudolog.c: In function ?parse_timestamp?:
| pseudolog.c:329:13: error: implicit declaration of function
?strptime?; did you mean ?strftime?? [-Wimplicit-function-declaration]
|   329 |         s = strptime(string, timeformat, &stamp_tm);
|       |             ^~~~~~~~
|       |             strftime
| pseudolog.c:329:11: error: assignment to ?char *? from ?int? makes
pointer from integer without a cast [-Wint-conversion]
|   329 |         s = strptime(string, timeformat, &stamp_tm);
|       |           ^
| pseudolog.c:337:19: error: assignment to ?char *? from ?int? makes
pointer from integer without a cast [-Wint-conversion]
|   337 |                 s = strptime(string, time_formats[i], &stamp_tm);
|       |                   ^
| pseudolog.c: In function ?plog_trait?:
| pseudolog.c:377:34: warning: ?calloc? sizes specified with ?sizeof?
in the earlier argument and not in the later argument
[-Wcalloc-transposed-args]
|   377 |         new_trait = calloc(sizeof(*new_trait), 1);
|       |                                  ^
| pseudolog.c:377:34: note: earlier argument should specify number of
elements, later size of each element
| make: *** [Makefile:130: pseudolog.o] Error 1

It's not caused by this change itself (it just triggers pseudo-native
to be rebuilt and not reused from sstate) but can we update to even
newer SRCREV which fixes this? Will check if
https://git.yoctoproject.org/pseudo/commit/pseudolog.c?id=15b4f4ca25593f684e6517d0b809605b443d1953
fixes all of them.


On Wed, Nov 6, 2024 at 7:13 PM Fabio Berton via lists.openembedded.org
<[email protected]> wrote:
>
> From: Richard Purdie <[email protected]>
>
> Update to pull in:
>
>     pseudo.c: Avoid patch mismatch errors for NAMELESS file entries
>
>     In rare cases we see failures, often in linux-libc-headers for things 
> like:
>
>     |   INSTALL /XXX/linux-libc-headers/6.1-r0/image/usr/include
>     | abort()ing pseudo client by server request. See 
> https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
>
>     Pseudo log:
>     path mismatch [2 links]: ino 46662476 db 'NAMELESS FILE' req 
> '/XXX/linux-libc-headers/6.1-r0/image/usr'.
>     Setup complete, sending SIGUSR1 to pid 3630890.
>
>     Whilst this doesn't easily reproduce, the issue is that multiple 
> different processes are
>     likely working on the directory and the creation in pseudo might not 
> match accesses
>     made by other processes.
>
>     Ultimately, the "NAMELESS FILE" is harmless and pseudo will reconcile 
> things
>     so rather than error out, we should ignore this case.
>
> Signed-off-by: Richard Purdie <[email protected]>
> Signed-off-by: Luca Ceresoli <[email protected]>
> Signed-off-by: Richard Purdie <[email protected]>
> (cherry picked from commit 4f30a1a74828e105cbe69677b3fbe5623f371543)
> Signed-off-by: Fabio Berton <[email protected]>
> ---
>  meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
> b/meta/recipes-devtools/pseudo/pseudo_git.bb
> index 4dd9156238..6b0cb598e2 100644
> --- a/meta/recipes-devtools/pseudo/pseudo_git.bb
> +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
> @@ -14,7 +14,7 @@ SRC_URI:append:class-nativesdk = " \
>      file://older-glibc-symbols.patch"
>  SRC_URI[prebuilt.sha256sum] = 
> "ed9f456856e9d86359f169f46a70ad7be4190d6040282b84c8d97b99072485aa"
>
> -SRCREV = "c9670c27ff67ab899007ce749254b16091577e55"
> +SRCREV = "cc1f6167cb5065daba1462056e2dce8ff72aa855"
>  S = "${WORKDIR}/git"
>  PV = "1.9.0+git${SRCPV}"
>
> --
> 2.25.1
>
> The information in this communication may contain confidential or legally 
> privileged information. It is intended solely for the use of the individual 
> or entity it addresses and others authorized to receive it. If you are not an 
> intended recipient, you are hereby notified that any disclosure, copying, 
> distribution or action in reliance on the contents of this information is 
> strictly prohibited and may be unlawful. If you have received this 
> communication by error, please notify us immediately by responding to this 
> e-mail and then delete it from your system. Critical TechWorks is not liable 
> for the proper and complete transmission of the information in this 
> communication nor for any delay in its receipt
>
> This e-mail is environmentally friendly, just like Critical TechWorks, which 
> lives in a paper-free atmosphere. Therefore, please consider the environment 
> before printing it!
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#206854): 
https://lists.openembedded.org/g/openembedded-core/message/206854
Mute This Topic: https://lists.openembedded.org/mt/109429860/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to