Re: [Buildroot] [PATCH] package/ncftp: fix GCC 14.x related build errors

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Yegor, All,

On 2024-06-13 13:51 +0200, Yegor Yefremov spake thusly:
[--SNIP--]
> But the third problem remains and I don't know how to fix this:
> 
> spoolutil.c: In function ‘WriteSpoolEntry’:
> spoolutil.c:286:38: error: passing argument 2 of ‘lstat’ from
> incompatible pointer type [-Wincompatible-pointer-types]
>   286 |                 if (lstat(lpathname, &st) == 0) {
>       |                                      ^~~
>       |                                      |
>       |                                      struct stat64 *
> In file included from
> /home/user/buildroot/bsp-barebox/per-package/ncftp/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/features.h:503,
>                  from
> /home/user/buildroot/bsp-barebox/per-package/ncftp/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/unistd.h:25,
>                  from syshdrs.h:143,
>                  from spoolutil.c:8:
> /home/user/buildroot/bsp-barebox/per-package/ncftp/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/sys/stat.h:327:12:
> note: expected ‘struct stat * restrict’ but argument is of type
> ‘struct stat64 *’
>   327 | extern int __REDIRECT_NTH (lstat,
>       |            ^~~~~~~~~~~~~~
> 
> The toolchain was built via BR for armv7 and glibc. Any ideas? Why
> should one use struct stat64 directly?

It looks like a little bit of magic to me, but what I take from the
__REDIRECT_NTH macro, is that it instructs the compiler (and linker) to
really redirect calls to lstat() to lstat64() instead (NTH) means no
throw, which is completely something else and of no conern here I
think).

So, it is again a misfit between 32-bit functions and 64-bit structure
(or the other way around).

I'vbe looked at the glibc source, and basically here is what it does in
bits/struct_stat.h:

    struct stat {
    #ifdef __USE_TIME_BITS64
    # include <bits/struct_stat_time64_helper.h>
    #else
    /* defines stat fields here ...*/
    #endif
    };

    #ifdef __USE_LARGEFILE64
    struct stat64{
    #ifdef __USE_TIME_BITS64
    # include <bits/struct_stat_time64_helper.h>
    #else
    /* defines stat64 fields here ...*/
    #endif
    };
    #endif

So, basically:

  - for 64-bit time, both structs are exactly the same.

  - for 32-bit time, they do differ, but the C library should do its
    magic:

    $ man lstat

    C library/kernel differences
        Over  time,  increases in the size of the stat structure have led
        to three successive versions of stat() [...]

        The  kernel-internal  versions  of the stat structure dealt with
        by the different versions are, respectively:

        __old_kernel_stat [...]
        stat [...]
        stat64 [...]

        The glibc stat() wrapper function hides these details from
        applications, invoking the most recent version of the system call
        provided by the kernel, and repacking the returned in‐ formation
        if required for old binaries.

With my limited understanding: "it should be fine!".

So yes, calls to lstat() should use struct stat. Or an explicit call to
lstat64() should be made, maybe?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot