Your message dated Fri, 10 Jan 2025 23:44:17 +0100 with message-id <Z4Giwf72wrZmnZjp@aurel32.net> 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 owner@bugs.debian.org immediately.) -- 898743: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898743 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: <sys/mount.h> breaks when #included after <linux/fs.h>
- From: Helmut Grohne <helmut@subdivi.de>
- Date: Tue, 15 May 2018 16:57:57 +0200
- Message-id: <20180515145756.GA20045@alf.mars>
Package: linux-libc-dev,libc6-dev Severity: serious Justification: makes systemd ftbfs User: helmutg@debian.org 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 ---
- To: Helmut Grohne <helmut@subdivi.de>
- Cc: 898743-done@bugs.debian.org
- Subject: Re: Bug#898743: <sys/mount.h> breaks when #included after <linux/fs.h>
- From: Aurelien Jarno <aurel32@debian.org>
- Date: Fri, 10 Jan 2025 23:44:17 +0100
- Message-id: <Z4Giwf72wrZmnZjp@aurel32.net>
- In-reply-to: <58d08279f6f230f99017190133d9fa1c60c57c8b.camel@decadent.org.uk>
- References: <20180515145756.GA20045@alf.mars> <20180515145756.GA20045@alf.mars> <58d08279f6f230f99017190133d9fa1c60c57c8b.camel@decadent.org.uk>
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 <helmut@subdivi.de> wrote: > > Package: linux-libc-dev,libc6-dev > > Severity: serious > > Justification: makes systemd ftbfs > > User: helmutg@debian.org > > 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 aurelien@aurel32.net http://aurel32.netAttachment: signature.asc
Description: PGP signature
--- End Message ---