Build failure on Rocky Linux 10: Missing glibc-devel.i686 (No 32-bit support)

[Suse-quantum]

Describe the bug
I am trying to build cephtrace on Rocky Linux 10, but the build fails because the system cannot find gnu/stubs-32.h.

It appears that the build process (specifically when compiling osdtrace.bpf.c) is attempting to compile 32-bit code or is picking up host headers that trigger 32-bit paths. However, Rocky Linux 10 (and RHEL 10) has dropped support for the i686 architecture, so the package glibc-devel.i686 is no longer available in the repositories.

To Reproduce
Steps to reproduce the behavior:

1. Fresh install of Rocky Linux 10 (Minimal or Standard).
2. Install dependencies (without i686, as it doesn't exist):

   sudo dnf install git make clang gcc-c++ elfutils-libelf-devel openssl-devel

3. Clone and build:

   git clone https://github.com/taodd/cephtrace
   cd cephtrace
   git submodule update --init --recursive
   make

Expected behavior
The project should build successfully on modern 64-bit only distributions without requiring 32-bit compatibility libraries.

Screenshots / Logs
The build fails with the following error:

Environment

• OS: Rocky Linux release 10.1 (Red Quartz)
• Kernel: 6.12.0-124.56.1.el10_1.x86_64
• GCC/Clang:

[root@localhost cephtrace]# clang -v
clang version 20.1.8 (RESF 20.1.8-1.el10)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Configuration file: /etc/clang/x86_64-redhat-linux-gnu-clang.cfg
System configuration file directory: /etc/clang/
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/11
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/14
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/8
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/14
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

[Suse-quantum]

I have successfully resolved this build failure on Rocky Linux 10. The root cause is not a missing 32-bit library, but rather a macro definition conflict between the BPF compilation target and the system's glibc headers.

Problem Analysis

When compiling BPF code using clang -target bpf, the compiler does not automatically define the standard architecture macros (like __x86_64__) that glibc headers rely on. Consequently, /usr/include/gnu/stubs.h incorrectly assumes a 32-bit target, triggering the misleading stubs-32.h not found error.

Solution

Instead of installing non-existent 32-bit libraries or hardcoding -D__x86_64__ (which would break ARM builds), I've modified the Makefile to dynamically detect the host architecture and inject the necessary native macro specifically for glibc.

Here is the patch to fix the issue:

--- a/Makefile.orig
+++ b/Makefile
@@ -25,7 +25,38 @@
 CLANG := clang
 CXX := g++
 OUTPUT := .output
-ARCH := $(shell uname -m | sed 's/x86_64/x86/' | sed 's/aarch64/arm64/' | sed 's/ppc64le/powerpc/' | sed 's/mips.*/mips/')
+
+# Get the native hardware architecture name of the host (e.g., x86_64, aarch64, ppc64le)
+UNAME_M := $(shell uname -m)
+
+# Define the architecture identifier for the BPF toolchain
+ifeq ($(UNAME_M),x86_64)
+    BPF_TARGET_ARCH := x86
+else ifeq ($(UNAME_M),aarch64)
+    BPF_TARGET_ARCH := arm64
+else ifeq ($(UNAME_M),ppc64le)
+    BPF_TARGET_ARCH := powerpc
+else ifneq ($(filter mips%, $(UNAME_M)),)
+    BPF_TARGET_ARCH := mips
+endif
+
+# Define the architecture macros required by glibc headers (to resolve stubs-32.h not found errors)
+ifeq ($(UNAME_M),x86_64)
+    GLIBC_ARCH_MACRO := -D__x86_64__
+else ifeq ($(UNAME_M),aarch64)
+    GLIBC_ARCH_MACRO := -D__aarch64__
+else ifeq ($(UNAME_M),ppc64le)
+    GLIBC_ARCH_MACRO := -D__powerpc64__
+else ifneq ($(filter mips%, $(UNAME_M)),)
+    # MIPS may have different macros based on endianness and word size; using common 64-bit little-endian as an example
+    GLIBC_ARCH_MACRO := -D__mips__
+endif
+
+# Inject both sets of definitions into the compilation flags
+# BPF_TARGET_ARCH is used for the existing __TARGET_ARCH logic
+# GLIBC_ARCH_MACRO is used to satisfy the system's glibc headers
+CXXFLAGS := -D__TARGET_ARCH_$(BPF_TARGET_ARCH) $(GLIBC_ARCH_MACRO)
+
 
 # Install location
 PREFIX ?= /usr
@@ -64,7 +95,7 @@
 # Compiler flags
 CLANG_BPF_SYS_INCLUDES := $(shell $(CLANG) -v -E - </dev/null 2>&1 | \
     sed -n '/<...> search starts here:/,/End of search list./{ s| $/.*$|-idirafter \1|p }')
-CXXFLAGS := -g -O2 -Wall -Wextra -Wno-unused-function -Wno-address-of-packed-member -D__TARGET_ARCH_$(ARCH) $(INCLUDES) $(CLANG_BPF_SYS_INCLUDES)
+CXXFLAGS += -g -O2 -Wall -Wextra -Wno-unused-function -Wno-address-of-packed-member  $(INCLUDES) $(CLANG_BPF_SYS_INCLUDES)
 LIBS := $(LIBBPF_OBJ) -lelf -ldw -lz -ldl
 
 # Build verbosity control

Instructions & Testing Note:

1. Apply this patch to local repository.
2. Run make clean && make to rebuild.

️ Note: This fix has been fully tested and verified on x86_64 architecture only. I currently do not have testing environments for other architectures (such as aarch64, ppc64le, or mips). While the dynamic detection logic should theoretically work across all supported platforms, further validation from the community on non-x86 systems would be highly appreciated.

[taodd]

@Suse-quantum Thanks for reporting the issue, would you mind to send a PR ?

[Suse-quantum]

Thanks! I’d rather not open a PR at the moment. The approach I shared seems to work in my case, but it may not be complete , so I wouldn’t feel comfortable turning it into an official fix.
Hopefully the context here helps the team decide how best to address it.