All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.