Re: [Buildroot] [PATCH] package/e2tools: fix build with uClibc on mips64

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello Yegor,

(+Waldemar in Cc)

On Tue, Sep 08, 2026 at 03:20:30PM +0200, Yegor Yefremov via buildroot wrote:

> diff --git a/package/e2tools/0001-write-do-not-pass-struct-stat-st_size-to-store_data.patch b/package/e2tools/0001-write-do-not-pass-struct-stat-st_size-to-store_data.patch
> new file mode 100644
> index 0000000000..86dd01192c
> --- /dev/null
> +++ b/package/e2tools/0001-write-do-not-pass-struct-stat-st_size-to-store_data.patch
> @@ -0,0 +1,74 @@
> +From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
> +From: Yegor Yefremov <yegorslists@googlemail.com>
> +Date: Tue, 8 Sep 2026 12:00:00 +0200
> +Subject: [PATCH] write: do not pass &statbuf.st_size to store_data()
> +
> +store_data() takes an 'off_t *', but put_file() hands it the address of
> +'statbuf.st_size', whose type is whatever the C library declares in
> +'struct stat'. Those two types are not required to match: on mips64
> +uClibc-ng declares 'struct stat::st_size' as '__off_t' (long int), while
> +'_FILE_OFFSET_BITS=64' makes 'off_t' an alias of '__off64_t' (long long
> +int). Both are 64 bit wide, but they are distinct types, so gcc 14 and
> +later reject the call:

Are you sure this is the correct fix?

When I look at stat(3type) it says:

       struct stat {
           dev_t      st_dev;      /* ID of device containing file */
           ino_t      st_ino;      /* Inode number */
           mode_t     st_mode;     /* File type and mode */
           nlink_t    st_nlink;    /* Number of hard links */
           uid_t      st_uid;      /* User ID of owner */
           gid_t      st_gid;      /* Group ID of owner */
           dev_t      st_rdev;     /* Device ID (if special file) */
           off_t      st_size;     /* Total size, in bytes */

So st_size is an off_t, so passing &blabla.st_size to a function
expecting an off_t* should always work.

And the fact that this (apparently) only occurs on uClibc makes me
think that this is more likely a uClibc bug.

Waldemar, do you have any thoughts?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot