From: Waldemar Brodkorb <wbx@openadk.org>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Julien Olivain <ju.o@free.fr>,
Marcus Folkesson <marcus.folkesson@gmail.com>,
Antoine Tenart <atenart@kernel.org>,
buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 01/11] package/libselinux: fix build issues caused by 3.8.1 bump
Date: Sat, 20 Sep 2025 08:07:56 +0200 [thread overview]
Message-ID: <aM5EvEkrOXv30D78@waldemar-brodkorb.de> (raw)
In-Reply-To: <20250919210040.6f247422@windsurf>
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]
Hi Thomas,
Thomas Petazzoni wrote,
> On Fri, 19 Sep 2025 20:42:30 +0200
> Waldemar Brodkorb <wbx@openadk.org> wrote:
>
> > > Dammit. I must say I don't quite grasp what they are trying to do in
> > > these matchpathcon.c checks.
> > >
> > > It seems like:
> > >
> > > #if (defined(_FILE_OFFSET_BITS) && _FILE_OFFSET_BITS == 64) && defined(__INO64_T_TYPE) && !defined(__INO_T_MATCHES_INO64_T)
> > > /* alias defined in the public header but we undefine it here */
> > > #undef matchpathcon_filespec_add
> > >
> > > /* ABI backwards-compatible shim for non-LFS 32-bit systems */
> > >
> > > static_assert(sizeof(unsigned long) == sizeof(__ino_t), "inode size mismatch");
> > > static_assert(sizeof(unsigned long) == sizeof(uint32_t), "inode size mismatch");
> > > static_assert(sizeof(ino_t) == sizeof(ino64_t), "inode size mismatch");
> > > static_assert(sizeof(ino64_t) == sizeof(uint64_t), "inode size mismatch");
> > >
> > > is for 32-bit systems? And here you are building for x86-64, but it
> > > gets detected as a 32-bit system, or something like that. Is it due to
> > > the fact that we always build with _FILE_OFFSET_BITS=64 even on 64-bit
> > > systems, where I guess it doesn't make sense because off_t is anyway
> > > going to always be 64-bit.
> >
> > So would the right fix to enable _FILE_OFFSET_BITS=64 only for
> > 32-bit systems? Or do you think something in uClibc-ng is wrong?
>
> Defining FILE_OFFSET_BITS=64 all the time works fine with everything
> but uClibc-ng, so I'm tempted to think that something else is wrong in
> uClibc-ng, but I'm not 100% sure.
__INO_T_MATCHES_INO64_T is a internal macro in glibc.
As uClibc-ng tries to be compatible to glibc we can add this macro.
What do you think about following patch, attached to this email?
best regards
Waldemar
[-- Attachment #2: 0001-Add-glibc-internal-macros-for-64-Bit-architectures.patch --]
[-- Type: text/x-diff, Size: 1243 bytes --]
From a3d56d059df62b4ad6eb5ddb9edd1bb59609397a Mon Sep 17 00:00:00 2001
From: Waldemar Brodkorb <wbx@openadk.org>
Date: Sat, 20 Sep 2025 07:58:14 +0200
Subject: [PATCH] Add glibc internal macros for 64 Bit architectures
To satisfy detection of LFS support add these glibc internal macros.
Fixes f.e. libselinux compile.
Reported-By: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
---
libc/sysdeps/linux/common/bits/typesizes.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/libc/sysdeps/linux/common/bits/typesizes.h b/libc/sysdeps/linux/common/bits/typesizes.h
index dcb2c3b0a..074758701 100644
--- a/libc/sysdeps/linux/common/bits/typesizes.h
+++ b/libc/sysdeps/linux/common/bits/typesizes.h
@@ -73,5 +73,15 @@
/* Number of descriptors that can fit in an `fd_set'. */
#define __FD_SETSIZE 1024
+#if __WORDSIZE == 64
+/* Tell the code that off_t and off64_t are actually the same type
+ for all ABI purposes, even if possibly expressed as different base types
+ for C type-checking purposes. */
+# define __OFF_T_MATCHES_OFF64_T 1
+
+/* Same for ino_t and ino64_t. */
+# define __INO_T_MATCHES_INO64_T 1
+
+#endif
#endif /* bits/typesizes.h */
--
2.47.3
[-- Attachment #3: Type: text/plain, Size: 150 bytes --]
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2025-09-20 6:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 12:08 [Buildroot] [PATCH 00/11] SELinux fixes and updates Thomas Petazzoni via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 01/11] package/libselinux: fix build issues caused by 3.8.1 bump Thomas Petazzoni via buildroot
2025-09-14 22:28 ` Julien Olivain via buildroot
2025-09-15 6:06 ` Thomas Petazzoni via buildroot
2025-09-19 18:42 ` Waldemar Brodkorb
2025-09-19 19:00 ` Thomas Petazzoni via buildroot
2025-09-20 6:07 ` Waldemar Brodkorb [this message]
2025-09-20 8:45 ` Thomas Petazzoni via buildroot
2025-09-19 12:59 ` Thomas Perale via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 02/11] package/libsemanage: fix build issue due to basename() Thomas Petazzoni via buildroot
2025-09-19 12:56 ` Thomas Perale via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 03/11] package/policycoreutils: fix build with musl due to getpass() Thomas Petazzoni via buildroot
2025-09-19 12:56 ` Thomas Perale via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 04/11] package/libselinux: bump version to 3.9 Thomas Petazzoni via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 05/11] package/checkpolicy: bump to version 3.9 Thomas Petazzoni via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 06/11] package/libsemanage: " Thomas Petazzoni via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 07/11] package/libsepol: " Thomas Petazzoni via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 08/11] package/policycoreutils: " Thomas Petazzoni via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 09/11] package/restorecond: " Thomas Petazzoni via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 10/11] package/selinux-python: " Thomas Petazzoni via buildroot
2025-09-09 12:08 ` [Buildroot] [PATCH 11/11] package/semodule-utils: " Thomas Petazzoni 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=aM5EvEkrOXv30D78@waldemar-brodkorb.de \
--to=wbx@openadk.org \
--cc=atenart@kernel.org \
--cc=buildroot@buildroot.org \
--cc=ju.o@free.fr \
--cc=marcus.folkesson@gmail.com \
--cc=thomas.petazzoni@bootlin.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