Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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