public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Thomas Goirand <zigo@debian.org>, 1000974@bugs.debian.org
Cc: Giovanni Mascellani <gio@debian.org>, xfslibs-dev@packages.debian.org
Subject: Bug#1000974: copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’?
Date: Sun, 5 Dec 2021 09:45:12 -0800	[thread overview]
Message-ID: <20211205174512.GP8467@magnolia> (raw)
In-Reply-To: <86067ed6-28c5-2591-b27a-80957166a9a9@debian.org>

On Sun, Dec 05, 2021 at 06:33:40PM +0100, Thomas Goirand wrote:
> On 12/5/21 4:50 PM, Giovanni Mascellani wrote:
> > reassign 1000974 xfslibs-dev
> > severity 1000974 important
> > retitle 1000974 xfs/linux.h defines common word "fallthrough" breaking
> > unrelated headers
> > thanks
> > 
> > Hi,
> > 
> > On 04/12/21 23:36, Thomas Goirand wrote:
> >> On 12/4/21 5:11 PM, Giovanni Mascellani wrote:
> >>> Could you try running that compilation command with g++ -E, so you can
> >>> see what BOOST_FALLTHROUGH is actually begin replaced with?
> >>
> >> Oh, sorry, now I get what you meant (did a c++ --help to understand what
> >> -E was doing). Here's the result in
> >> CMakeFiles/seastar.dir/src/core/file.cc.o:
> >>
> >> __attribute__((__attribute__((__fallthrough__))));
> >>
> >> Probably, there's a mistake, and it should really be:
> >>
> >> __attribute__((__fallthrough__));
> >>
> >> instead, which is the source of the trouble?
> > 
> > It seems that the problem goes this way:
> > 
> >  * Boost defines in /usr/include/boost/config/compiler/gcc.hpp:
> > 
> > #define BOOST_FALLTHROUGH __attribute__((fallthrough))
> > 
> >  * But /usr/include/xfs/linux.h defines:
> > 
> > #define fallthrough __attribute__((__fallthrough__))
> > 
> > So the "fallthrough" in Boost's definition is expanded again and causes
> > the problem.
> > 
> > I think xfs/linux.h is at fault here, because it aggressively defines a
> > common word (while Boost namespaces all its definitions with a BOOST_
> > prefix). Unfortunately the C/C++ preprocessor makes it easy to break
> > other headers if you define stuff too liberally. This wold also, for
> > example, break any program that use the name "fallthrough" for a
> > variable, which is a completely reasonable name to use. A simple example
> > could be:
> > ---
> > #include <xfs/linux.h>
> > 
> > int main() {
> >     int fallthrough = 0;
> >     return fallthrough;
> > }
> > ---
> > which fails compilation with:
> > ---
> > $ LANG=C gcc test.c
> > test.c: In function 'main':
> > test.c:4:5: warning: 'fallthrough' attribute not followed by ';'
> > [-Wattributes]
> >     4 |     int fallthrough = 0;
> >       |     ^~~
> > test.c:4:21: error: expected identifier or '(' before '=' token
> >     4 |     int fallthrough = 0;
> >       |                     ^
> > In file included from test.c:1:
> > test.c:5:12: error: expected expression before '__attribute__'
> >     5 |     return fallthrough;
> >       |            ^~~~~~~~~~~
> > ---
> > 
> > You can probably work around this problem by undefining "fallthrough"
> > just after the xfs/linux.h header. In the meantime I am reassigning this
> > bug to xfslibs-dev.

Yeah, sorry.  This is braindamage from the Linux kernel (because hey, we
share libxfs between kernel and userspace) that I mistakenly let escape
because the authors of the kernel patch didn't try to help us when they
forced this stupid mess on us.  All this BS because some compiler
writers didn't like their static checkers to have to use regular
expressions for compatibility with existing codebases, and the language
standard people decided to introduce a breaking change to "standardize"
it.

Will fix ASAP.

--D

> > 
> > Giovanni.
> 
> 
> Hi,
> 
> I can confirm that commenting away line 373 to 381 of xfs/linux.h solve
> the troubles when building Ceph. Downgrading to 5.13.0-1 (using
> snapshot.d.o) also solved the trouble, showing that 5.14.0 really is the
> trouble here.
> 
> Thanks Giovanni for finding this out.
> 
> Cheers,
> 
> Thomas Goirand (zigo)

  reply	other threads:[~2021-12-05 17:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9b9bda73-9554-0c75-824d-f8d1b9b98e19@debian.org>
     [not found] ` <7686ac7e-0df1-a98c-27ce-51dc5e46c55e@debian.org>
     [not found]   ` <163839370805.58768.6385074074873965943.reportbug@zbuz.infomaniak.ch>
     [not found]     ` <c7ccff50-c177-7f96-2d99-2077f77374ad@debian.org>
2021-12-05 15:57       ` Processed (with 1 error): Re: Bug#1000974: copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’? Debian Bug Tracking System
2021-12-05 17:33       ` Thomas Goirand
2021-12-05 17:45         ` Darrick J. Wong [this message]
2021-12-05 17:49     ` [PATCH xfsprogs-5.14.2 URGENT] libxfs: hide the drainbamaged fallthrough macro from xfslibs Darrick J. Wong
2021-12-05 17:49       ` Bug#1000974: " Darrick J. Wong
2021-12-05 21:10       ` Dave Chinner
2021-12-05 21:10         ` Dave Chinner
2021-12-06 14:26       ` Eric Sandeen
2021-12-06 14:26         ` Bug#1000974: " Eric Sandeen
2021-12-06 20:15       ` Kees Cook
2021-12-06 20:15         ` Bug#1000974: " Kees Cook
     [not found]     ` <handler.1000974.B1000974.163872562421581.ackinfo@bugs.debian.org>
2021-12-05 19:00       ` Bug#1000974: Info received (Bug#1000974: copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’?) Thomas Goirand
2021-12-07 12:36     ` Bug#1000974: marked as done (xfs/linux.h defines common word "fallthrough" breaking unrelated headers) Debian Bug Tracking System
2021-12-07 12:54     ` Debian Bug Tracking System

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211205174512.GP8467@magnolia \
    --to=djwong@kernel.org \
    --cc=1000974@bugs.debian.org \
    --cc=gio@debian.org \
    --cc=xfslibs-dev@packages.debian.org \
    --cc=zigo@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox