[Bug libc/30798] New: sysdeps/nptl/lowlevellock.h and lowlevellock-futex.h

[Bug libc/30798] New: sysdeps/nptl/lowlevellock.h and lowlevellock-futex.h

[asholomitskiy84 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30798

            Bug ID: 30798
           Summary: sysdeps/nptl/lowlevellock.h and lowlevellock-futex.h
           Product: glibc
           Version: 2.31
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: asholomitskiy84 at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 15089
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15089&action=edit
my system description

Hi!
Please, forgive me for long letter:)
I have Linux Mint 20.3 x86_64 with glibc 2.31-0ubuntu9.9 (system.txt applied)
Original system kernel was 5.4.126 (from repository), and native system header
file /usr/include/linux/version.h defines LINUX_VERSION_CODE 328907 (i.e. 5.4).
Some time later I have installed linux-5.15.79 from repository, after that I
first time build kernel 5.15.79 from source. Mannually built kernel works
without problems, like it was from repository and as similar size. Ok.

my question: I'd like to try build glibc-2.31 manually, but with new kernel
headers 5.15.79, can I do it?
I understand, different Linux systems have different patches, in order to have
less problems I downloded sources by:
$ apt-get source glibc

$ cd glibc-2.31
$ mkdir mybuild; cd mybuild
$ ../configure --prefix=/tools/glibc-2.31 --disable-werror
--enable-kernel=5.15.0 --with-selinux --enable-stack-protector=strong
--with-headers=/usr/local/lib/modules/5.15.79/source/include --with-tls
--enable-add-ons --enable-multi-arch --enable-nss-crypt --enable-pt_chown
--enable-tunables=yes --enable-shared

$ make returns many warnings, but the difficult errors are:
1) sysdeps/generic/_itoa.h::36:30: error: missing binary operator before token
"("
# define _ITOA_NEEDED (LONG_MAX != LLONG_MAX)
I had similar errors but I solved them by making additional symlinks inside
headers folder for files with types description.

I looked for '(LONG_MAX' reason, but nothing found and replaced string to
# define _ITOA_NEEDED 0 // (LONG_MAX != LLONG_MAX)

2) I stopped at sysdeps/nptl/lowlevellock.h and lowlevellock-futex.h
error: expected expression before ‘)’ token
../sysdeps/nptl/lowlevellock.h:173:20:
173 |      int __private = (private);
                                   ^
sysdeps/nptl/lowlevellock-futex.h:60:39: 
60 |     __lll_private_flag_priv = (private);
                                           ^
C_INCLUDE_PATH=/usr/local/include:/usr/src/linux-5.15.79/include:/usr/include:/usr/include/x86_64-linux-gnu
CPP_INCLUDE_PATH has the same value (another variables in system.txt)

I tried to build glibc-2.31 on another system:
Debian 11.0 with glibc 2.31-13+deb11u3 (clean install), but have the same
errors

Also I tried compiled glibc-2.31 and glibc-2.34 from
https://ftp.gnu.org/gnu/glibc/  , but without success

mayby I could build glibc only with native /usr/include headers only?
Could you give me a tip to solve this error?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30798] sysdeps/nptl/lowlevellock.h and lowlevellock-futex.h

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30798

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Alexei Sholomitskiy from comment #0)
> my question: I'd like to try build glibc-2.31 manually, but with new kernel
> headers 5.15.79, can I do it?

Why do you want to do that?  These days, we try to make sure that the built
glibc (and its included features) does not depend on the kernel header version.

> I understand, different Linux systems have different patches, in order to
> have less problems I downloded sources by:
> $ apt-get source glibc
> 
> $ cd glibc-2.31
> $ mkdir mybuild; cd mybuild
> $ ../configure --prefix=/tools/glibc-2.31 --disable-werror
> --enable-kernel=5.15.0 --with-selinux --enable-stack-protector=strong
> --with-headers=/usr/local/lib/modules/5.15.79/source/include --with-tls
> --enable-add-ons --enable-multi-arch --enable-nss-crypt --enable-pt_chown
> --enable-tunables=yes --enable-shared

You need to configure with --prefix=/usr. For compatibility with Debian
multi-arch, you need additional flags and maybe patches. Debian hasn't
upstreamed their multi-arch implementation.

Your problems maybe caused by
--with-headers=/usr/local/lib/modules/5.15.79/source/include because as far as
I understand it, this is a path that is used for the kernel module headers, but
you need the UAPI headers for building glibc.

This topic is more suited to the libc-help mailing list.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30798] sysdeps/nptl/lowlevellock.h and lowlevellock-futex.h

[asholomitskiy84 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30798

Alexei Sholomitskiy <asholomitskiy84 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Build|                            |x86_64
               Host|                            |x86_64

--- Comment #2 from Alexei Sholomitskiy <asholomitskiy84 at gmail dot com> ---
I should write, that build without option
--with-headers=/usr/local/lib/modules/5.15.79/source/include (and option
--enable-kernel changed to --enable-kernel=5.4.0) was successful

But I'd like to understand building process
why there are errors.

After I tried compile libaio from source with C_INCULDE_PATH contained path to
new headers, I had errors like:
unknown type name ‘bool’
unknown type name ‘long’

It very dissapoint me

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30798] sysdeps/nptl/lowlevellock.h and lowlevellock-futex.h

[asholomitskiy84 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30798

--- Comment #3 from Alexei Sholomitskiy <asholomitskiy84 at gmail dot com> ---
Hi, Florian

I use Linux about 2 yeras, but I have never built kernel from source
So I am a novice and I was interested to learn this question

*Why do you want to do that?*

Though there are many documentation about glibc, I have not met 
instructions about using new kernel uap headers with glibc. On any error 
I made links to different files inside headers directory.
To my mind ./configure --help says, that it will compile for 
compatibility with kernel not older VERSION.
So my exepectations were: --enable-kernel option can make library for 
new linux-5.15.79 kernel, without unnecessary compability with older 
kernels. That's why my next step was to define path headers location by 
--with-headers option.
Also I believed, that building glibc with the same version, that is 
native for my Linux system, will not break it.


28.08.2023 13:29, fweimer at redhat dot com пишет:
> https://sourceware.org/bugzilla/show_bug.cgi?id=30798
>
> Florian Weimer <fweimer at redhat dot com> changed:

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/30798] sysdeps/nptl/lowlevellock.h and lowlevellock-futex.h

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30798

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Alexei Sholomitskiy from comment #3)
> Though there are many documentation about glibc, I have not met 
> instructions about using new kernel uap headers with glibc. On any error 
> I made links to different files inside headers directory.
> To my mind ./configure --help says, that it will compile for 
> compatibility with kernel not older VERSION.
> So my exepectations were: --enable-kernel option can make library for 
> new linux-5.15.79 kernel, without unnecessary compability with older 
> kernels. That's why my next step was to define path headers location by 
> --with-headers option.

--enable-kernel does not need the corresponding kernel headers.

> Also I believed, that building glibc with the same version, that is 
> native for my Linux system, will not break it.

The Debian multi-arch patches/configuration defaults are not upstream, so it's
difficult to build a compatible replacement for the system glibc. On many other
systems, ./configure --prefix=/usr will give you a functioning glibc (although
you need to be careful and use make install with DESTDIR=…). But that won't
work on Debian and derived systems.

For the UAPI headers, you probably should use the .deb build target (available
in the upstream sources) and install the headers package, then you don't need
to set the path.

-- 
You are receiving this mail because:
You are on the CC list for the bug.