Your message dated Fri, 10 Jan 2025 23:44:17 +0100
with message-id <[email protected]>
and subject line Re: Bug#898743: <sys/mount.h> breaks when #included after
<linux/fs.h>
has caused the Debian Bug report #898743,
regarding <sys/mount.h> breaks when #included after <linux/fs.h>
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
898743: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898743
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: linux-libc-dev,libc6-dev
Severity: serious
Justification: makes systemd ftbfs
User: [email protected]
Usertags: rebootstrap
Control: affects -1 + src:systemd libmount-dev
systemd FTBFS here, because compiling load-fragment.c fails. I spent a while
minimizing that file and it boils down to:
$ cat test.c
#include <linux/fs.h>
#include <sys/mount.h>
$ gcc -c test.c
In file included from test.c:1:0:
/usr/include/x86_64-linux-gnu/sys/mount.h:35:3: error: expected identifier
before numeric constant
MS_RDONLY = 1, /* Mount read-only. */
^
$
linux/fs.h #defines MS_RDONLY and then sys/mount.h tries to create an
enum containing MS_RDONLY. That's a problem.
This is also known in fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1497501
That bug hints that sometimes headers need to #included in a certain
order. If that is the case, this bug should be reassigned to src:systemd
asking that <libmount.h> or <sys/mount.h> must be #included before
<linux/fs.h>. It also means that <libmount.h> should #include
<sys/mount.h> before defining its own copies of these macros.
Helmut
PS: Let me briefly curse systemd for their use of cyclic #includes
(unit.h <-> cgroup.h) and #pragma once as that works pretty badly
with creduce. Thank you.
--- End Message ---
--- Begin Message ---
Version: 2.37-1
Hi,
On 2019-02-10 00:50, Ben Hutchings wrote:
> Control: reassign -1 libc6-dev
> Control: severity -1 normal
>
> On Tue, 15 May 2018 16:57:57 +0200 Helmut Grohne <[email protected]> wrote:
> > Package: linux-libc-dev,libc6-dev
> > Severity: serious
> > Justification: makes systemd ftbfs
> > User: [email protected]
> > Usertags: rebootstrap
> > Control: affects -1 + src:systemd libmount-dev
> >
> > systemd FTBFS here, because compiling load-fragment.c fails. I spent a while
> > minimizing that file and it boils down to:
> >
> > $ cat test.c
> > #include <linux/fs.h>
> > #include <sys/mount.h>
> > $ gcc -c test.c
> > In file included from test.c:1:0:
> > /usr/include/x86_64-linux-gnu/sys/mount.h:35:3: error: expected identifier
> > before numeric constant
> > MS_RDONLY = 1, /* Mount read-only. */
> > ^
> > $
> >
> > linux/fs.h #defines MS_RDONLY and then sys/mount.h tries to create an
> > enum containing MS_RDONLY. That's a problem.
> [...]
>
> <linux/fs.h> has defined MS_RDONLY as a macro since before version 1.0,
> so this is a wontfix on the kernel side. <sys/mount.h> was already
> defining MS_RDONLY as both enumerator and macro in jessie, so this
> doesn't seem to be a regression.
This has been fixed in glibc 2.37. Closing the bug accordingly.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
[email protected] http://aurel32.net
signature.asc
Description: PGP signature
--- End Message ---
