Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yegor Yefremov via buildroot <buildroot@buildroot.org>
To: buildroot@buildroot.org
Subject: [Buildroot] [PATCH] package/e2tools: fix build with uClibc on mips64
Date: Tue,  8 Sep 2026 15:20:30 +0200	[thread overview]
Message-ID: <20260908132030.3792569-1-yegorslists@gmail.com> (raw)

From: Yegor Yefremov <yegorslists@googlemail.com>

put_file() passes &statbuf.st_size to store_data(), which takes an
'off_t *'. On mips64 those types do not match: uClibc-ng declares
'struct stat::st_size' as '__off_t' (long int) for the N32/N64 ABI,
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:

src/write.c: In function 'put_file':
src/write.c:237:45: error: passing argument 4 of 'store_data' from incompatible pointer type [-Wincompatible-pointer-types]
  237 |       (retval = store_data(fs, fd, newfile, &statbuf.st_size)))
      |                                             ^~~~~~~~~~~~~~~~
      |                                             |
      |                                             __off_t * {aka long int *}

Add a patch using a local 'off_t' variable instead, copying the size
reported by store_data() back into statbuf.

Fixes:
https://autobuild.buildroot.org/results/49754464e5daf87f69de8a79d7e6d607c00c78e2/

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
---
 ...ss-struct-stat-st_size-to-store_data.patch | 74 +++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 package/e2tools/0001-write-do-not-pass-struct-stat-st_size-to-store_data.patch

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:
+
+src/write.c: In function 'put_file':
+src/write.c:237:45: error: passing argument 4 of 'store_data' from incompatible pointer type [-Wincompatible-pointer-types]
+  237 |       (retval = store_data(fs, fd, newfile, &statbuf.st_size)))
+      |                                             ^~~~~~~~~~~~~~~~
+      |                                             |
+      |                                             __off_t * {aka long int *}
+src/write.c:49:63: note: expected 'off_t *' {aka 'long long int *'} but argument is of type '__off_t *' {aka 'long int *'}
+   49 | store_data(ext2_filsys fs, int fd, ext2_ino_t newfile, off_t *file_size);
+      |                                                        ~~~~~~~^~~~~~~~~
+
+Use a local 'off_t' variable instead and copy the size store_data()
+reports back into statbuf, which is what the code below (the stdin case,
+where the size is only known after the copy) relies on.
+
+Upstream: https://github.com/e2tools/e2tools/pull/40
+Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
+Assisted-by: Claude:claude-opus-5
+---
+ src/write.c | 19 ++++++++++++++-----
+ 1 file changed, 14 insertions(+), 5 deletions(-)
+
+diff --git a/src/write.c b/src/write.c
+index 1111111..2222222 100644
+--- a/src/write.c
++++ b/src/write.c
+@@ -114,6 +114,7 @@ put_file(ext2_filsys fs, ext2_ino_t cwd, char *infile, char *outfile,
+   long  retval;
+   struct ext2_inode inode;
+   mode_t cur_umask;
++  off_t file_size;
+ 
+   if (fs == NULL || outfile == NULL)
+     {
+@@ -233,15 +234,19 @@ put_file(ext2_filsys fs, ext2_ino_t cwd, char *infile, char *outfile,
+       return (retval);
+     }
+ 
+-  if (LINUX_S_ISREG(inode.i_mode) &&
+-      (retval = store_data(fs, fd, newfile, &statbuf.st_size)))
++  if (LINUX_S_ISREG(inode.i_mode))
+     {
+-      close(fd);
++      file_size = statbuf.st_size;
++      if ((retval = store_data(fs, fd, newfile, &file_size)))
++        {
++          close(fd);
+ #ifndef DEBUG
+-      rm_file(fs, cwd, outfile, newfile);
++          rm_file(fs, cwd, outfile, newfile);
+ 
+ #endif
+-      return(retval);
++          return(retval);
++        }
++      statbuf.st_size = file_size;
+     }
+ 
+   close(fd);
+-- 
+2.51.0
+
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

             reply	other threads:[~2026-09-08 13:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 13:20 Yegor Yefremov via buildroot [this message]
2026-09-18 19:45 ` [Buildroot] [PATCH] package/e2tools: fix build with uClibc on mips64 Thomas Petazzoni via buildroot
2026-09-19  6:40   ` Waldemar Brodkorb
2026-09-19  6:52     ` Yegor Yefremov via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260908132030.3792569-1-yegorslists@gmail.com \
    --to=buildroot@buildroot.org \
    --cc=yegorslists@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox