checking if compiling with clang... no configure: LTO is disabled checking if posix_spawn returns properly on failure... yes checking for readline... yes checking for io_setup in -laio... yes checking for liburing.h... no configure: error: Install liburing library and headers or use --disable-linux-io_uring !!! Please attach the following file when seeking support: ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_musl-20240824-035506 UNMASKED: Please re-assign to toolchain@ if you get a test failure in C, C++, or Fortran code which makes no sense. /etc/portage/package.unmask/60gcc:<sys-devel/gcc-15.0.9999:15 The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-musl-15 * clang/llvm (if any): clang version 18.1.8 Target: x86_64-pc-linux-musl Thread model: posix InstalledDir: /usr/lib/llvm/18/bin Configuration file: /etc/clang/x86_64-pc-linux-musl-clang.cfg /usr/lib/llvm/18 18.1.8 Python 3.12.5 Available Ruby profiles: [1] ruby31 (with Rubygems) [2] ruby32 (with Rubygems) [3] ruby33 (with Rubygems) * Available Rust versions: [1] rust-bin-1.80.1 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 11.0.24_p8 [openjdk-bin-11] 2) Eclipse Temurin JDK 17.0.12_p7 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.4_p7 [openjdk-bin-21] Available Java Virtual Machines: [1] openjdk-bin-11 [2] openjdk-bin-17 [3] openjdk-bin-21 system-vm php cli (if any): go version go1.23.0 linux/amd64 HEAD of ::gentoo commit 793dbdf7dc2099edd7c345df442652851573ca1f Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Tue Sep 3 21:23:22 2024 +0000 2024-09-03 21:23:22 UTC emerge -qpvO =sys-cluster/glusterfs-11.1 [ebuild N ] sys-cluster/glusterfs-11.1 USE="fuse ipv6 (libtirpc) uring -debug -emacs -georeplication -rsyslog (-selinux) -static-libs -tcmalloc -test -xml" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11"
Created attachment 902018 [details] emerge-info.txt
Created attachment 902019 [details] emerge-history.txt.xz
Created attachment 902020 [details] environment
Created attachment 902021 [details] etc.clang.tar.xz
Created attachment 902022 [details] etc.portage.tar.xz
Created attachment 902023 [details] logs.tar.xz
Created attachment 902024 [details] qlist-info.txt.xz
Created attachment 902025 [details] sys-cluster:glusterfs-11.1:20240903-221327.log
Created attachment 902026 [details] temp.tar.xz
configure:18573: x86_64-pc-linux-musl-gcc -c -O2 -pipe -march=native -fno-diagnostics-color -fsigned-char conftest.c >&5 In file included from conftest.c:107: /usr/include/liburing.h:224:39: error: unknown type name 'cpu_set_t' 224 | const cpu_set_t *mask); | ^~~~~~~~~ /usr/include/liburing.h:1248:48: error: unknown type name 'loff_t'; did you mean 'off_t'? 1248 | int fd, loff_t len) | ^~~~~~ | off_t configure:18573: $? = 1 configure: failed program was: In the liburing.h I already see this (liburing-2.3-r4): 9 #ifndef _GNU_SOURCE 10 #define _GNU_SOURCE /* Required for musl to expose cpu_set_t */ 11 #endif Which is already stable, and in fact the build here used sys-libs/liburing-2.7-r1 which is even newer. Not sure how liburing even manages to install in these conditions, but plainly the mechanism. Could it be an ordering of includes? I don't see that the test program includes <sched.h>, so somehow this feels unlikely, but shced.h does belong to glibc. Can the musl team please advise? I wonder if sched.h isn't somehow included from one of the following *before* liburing.h and thus why it's failing to then include the correct bits: | #include <stddef.h> | #ifdef HAVE_STDIO_H | # include <stdio.h> | #endif | #ifdef HAVE_STDLIB_H | # include <stdlib.h> | #endif | #ifdef HAVE_STRING_H | # include <string.h> | #endif | #ifdef HAVE_INTTYPES_H | # include <inttypes.h> | #endif | #ifdef HAVE_STDINT_H | # include <stdint.h> | #endif | #ifdef HAVE_STRINGS_H | # include <strings.h> | #endif | #ifdef HAVE_SYS_TYPES_H | # include <sys/types.h> | #endif | #ifdef HAVE_SYS_STAT_H | # include <sys/stat.h> | #endif | #ifdef HAVE_UNISTD_H | # include <unistd.h> | #endif | #include <liburing.h> IMHO that would be a musl problem since sched.h normally belongs to glibc, and I'm assuming musl provides that then.
Feature test macros like _GNU_SOURCE must be defined before including any standard headers, so the hack in liburing isn't super reliable. _If_ the liburing header is standalone (includes everything it needs), then you can just include that first and everything should be fine (move it above the bits you pasted).
configure.ac has this: 1628 case $host_os in 1629 linux*) 1630 AC_ARG_ENABLE([linux_io_uring], 1631 AS_HELP_STRING([--disable-linux-io_uring],[Disable io-uring support.])) 1632 1633 if test "x$enable_linux_io_uring" != "xno" ; then 1634 AC_CHECK_HEADERS([liburing.h], 1635 [AC_DEFINE(HAVE_LIBURING, 1, [io-uring based POSIX enabled]) LIBURING="-luring"], 1636 AC_MSG_ERROR([Install liburing library and headers or use --disable-linux-io_uring])) 1637 BUILD_LIBURING=yes 1638 1639 AC_CHECK_HEADER([linux/io_uring.h], 1640 [ 1641 AC_DEFINE([HAVE_IO_URING], [1], "io_uring support") 1642 BUILD_LINUX_IO_URING="yes" 1643 ]) 1644 fi 1645 ;; 1646 esac So how should that be modified? This should that the header should be standalone: jkroon@plastiekpoot ~/src/test $ cat uring.c #include <liburing.h> int main() { return 0; } jkroon@plastiekpoot ~/src/test $ make uring gcc -W -Wall -Werror -O0 -march=native -o uring.o -c uring.c gcc -O0 -o uring uring.o rm uring.o jkroon@plastiekpoot ~/src/test $ ./uring jkroon@plastiekpoot ~/src/test $
