From: "Darrick J. Wong" <djwong@kernel.org>
To: Sam James <sam@gentoo.org>
Cc: kernel@mattwhitlock.name, linux-xfs@vger.kernel.org, hch@lst.de
Subject: Re: [RFC PATCH] libxfs: compile with a C++ compiler
Date: Wed, 28 Aug 2024 16:53:41 -0700 [thread overview]
Message-ID: <20240828235341.GD6224@frogsfrogsfrogs> (raw)
In-Reply-To: <87le0hbjms.fsf@gentoo.org>
On Wed, Aug 28, 2024 at 01:01:31AM +0100, Sam James wrote:
> "Darrick J. Wong" <djwong@kernel.org> writes:
>
> > From: Darrick J. Wong <djwong@kernel.org>
> >
> > Apparently C++ compilers don't like the implicit void* casts that go on
> > in the system headers. Compile a dummy program with the C++ compiler to
> > make sure this works, so Darrick has /some/ chance of figuring these
> > things out before the users do.
>
> Thanks, this is a good idea. Double thanks for the quick fix.
>
> 1) yes, it finds the breakage:
> Tested-by: Sam James <sam@gentoo.org>
>
> 2) with the fix below (CC -> CXX):
> Reviewed-by: Sam James <sam@gentoo.org>
>
> 3) another thing to think about is:
> * -pedantic?
-pedantic won't build because C++ doesn't support flexarrays:
In file included from ../include/xfs.h:61:
../include/xfs/xfs_fs.h:523:33: error: ISO C++ forbids flexible array member ‘bulkstat’ [-Werror=pedantic]
523 | struct xfs_bulkstat bulkstat[];
| ^~~~~~~~
even if you wrap it in extern "C" { ... };
> * maybe do one for a bunch of standards? (I think systemd does every
> possible value [1])
That might be overkill since xfsprogs' build system doesn't have a good
mechanism for detecting if a compiler supports a particular standard.
I'm not even sure there's a good "reference" C++ standard to pick here,
since the kernel doesn't require a C++ compiler.
> * doing the above for C as well
Hmm, that's a good idea.
I think the only relevant standard here is C11 (well really gnu11),
because that's what the kernel compiles with since 5.18. xfsprogs
doesn't specify any particular version of C, but perhaps we should match
the kernel every time they bump that up?
IOWs, should we build xfsprogs with -std=gnu11? The commit changing the
kernel to gnu11 (e8c07082a810) remarks that gcc 5.1 supports it just
fine. IIRC RHEL 7 only has 4.8.5 but it's now in extended support so
... who cares? The oldest supported Debian stable has gcc 8.
--D
> I know that sounds a bit like overkill, but systemd
> does it and it's cheap to do it versus the blowup if something goes
> wrong. I don't have a strong opinion on this or how far you want to go
> with it.
>
> [1] https://github.com/systemd/systemd/blob/3317aedff0901e08a8efc8346ad76b184d5d40ea/src/systemd/meson.build#L60
>
> >
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> > configure.ac | 1 +
> > include/builddefs.in | 7 +++++++
> > libxfs/Makefile | 8 +++++++-
> > libxfs/dummy.cpp | 15 +++++++++++++++
> > 4 files changed, 30 insertions(+), 1 deletion(-)
> > create mode 100644 libxfs/dummy.cpp
> >
> > diff --git a/configure.ac b/configure.ac
> > index 0ffe2e5dfc53..04544f85395b 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -9,6 +9,7 @@ AC_PROG_INSTALL
> > LT_INIT
> >
> > AC_PROG_CC
> > +AC_PROG_CXX
> > AC_ARG_VAR(BUILD_CC, [C compiler for build tools])
> > if test "${BUILD_CC+set}" != "set"; then
> > if test $cross_compiling = no; then
> > diff --git a/include/builddefs.in b/include/builddefs.in
> > index 44f95234d21b..0f312b8b88fe 100644
> > --- a/include/builddefs.in
> > +++ b/include/builddefs.in
> > @@ -14,6 +14,7 @@ MALLOCLIB = @malloc_lib@
> > LOADERFLAGS = @LDFLAGS@
> > LTLDFLAGS = @LDFLAGS@
> > CFLAGS = @CFLAGS@ -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wno-address-of-packed-member
> > +CXXFLAGS = @CXXFLAGS@ -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wno-address-of-packed-member
> > BUILD_CFLAGS = @BUILD_CFLAGS@ -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
> >
> > # make sure we don't pick up whacky LDFLAGS from the make environment and
> > @@ -234,9 +235,15 @@ ifeq ($(ENABLE_GETTEXT),yes)
> > GCFLAGS += -DENABLE_GETTEXT
> > endif
> >
> > +# Override these if C++ needs other options
> > +SANITIZER_CXXFLAGS = $(SANITIZER_CFLAGS)
> > +GCXXFLAGS = $(GCFLAGS)
> > +PCXXFLAGS = $(PCFLAGS)
> > +
> > BUILD_CFLAGS += $(GCFLAGS) $(PCFLAGS)
> > # First, Sanitizer, Global, Platform, Local CFLAGS
> > CFLAGS += $(FCFLAGS) $(SANITIZER_CFLAGS) $(OPTIMIZER) $(GCFLAGS) $(PCFLAGS) $(LCFLAGS)
> > +CXXFLAGS += $(FCXXFLAGS) $(SANITIZER_CXXFLAGS) $(OPTIMIZER) $(GCXXFLAGS) $(PCXXFLAGS) $(LCXXFLAGS)
> >
> > include $(TOPDIR)/include/buildmacros
> >
> > diff --git a/libxfs/Makefile b/libxfs/Makefile
> > index 1185a5e6cb26..bb851ab74204 100644
> > --- a/libxfs/Makefile
> > +++ b/libxfs/Makefile
> > @@ -125,6 +125,8 @@ CFILES = buf_mem.c \
> > xfs_trans_space.c \
> > xfs_types.c
> >
> > +LDIRT += dummy.o
> > +
> > #
> > # Tracing flags:
> > # -DMEM_DEBUG all zone memory use
> > @@ -144,7 +146,11 @@ LTLIBS = $(LIBPTHREAD) $(LIBRT)
> > # don't try linking xfs_repair with a debug libxfs.
> > DEBUG = -DNDEBUG
> >
> > -default: ltdepend $(LTLIBRARY)
> > +default: ltdepend $(LTLIBRARY) dummy.o
> > +
> > +dummy.o: dummy.cpp
> > + @echo " [CXX] $@"
> > + $(Q)$(CC) $(CXXFLAGS) -c $<
>
> $(CXX) ;)
>
> >
> > # set up include/xfs header directory
> > include $(BUILDRULES)
> > diff --git a/libxfs/dummy.cpp b/libxfs/dummy.cpp
> > new file mode 100644
> > index 000000000000..a872c00ad84b
> > --- /dev/null
> > +++ b/libxfs/dummy.cpp
> > @@ -0,0 +1,15 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2024 Oracle. All Rights Reserved.
> > + * Author: Darrick J. Wong <djwong@kernel.org>
> > + */
> > +#include "include/xfs.h"
> > +#include "include/handle.h"
> > +#include "include/jdm.h"
> > +
> > +/* Dummy program to test C++ compilation of user-exported xfs headers */
> > +
> > +int main(int argc, char *argv[])
> > +{
> > + return 0;
> > +}
>
> cheers,
> sam
next prev parent reply other threads:[~2024-08-28 23:53 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 23:33 [PATCHSET v4.1] xfs: cleanups for inode rooted btree code Darrick J. Wong
2024-08-27 23:33 ` [PATCH 01/10] xfs: fix C++ compilation errors in xfs_fs.h Darrick J. Wong
2024-08-28 4:09 ` Christoph Hellwig
2024-08-29 1:29 ` Dave Chinner
2024-09-02 15:20 ` Carlos Maiolino
2024-08-27 23:34 ` [PATCH 02/10] xfs: fix FITRIM reporting again Darrick J. Wong
2024-08-28 4:10 ` Christoph Hellwig
2024-08-27 23:34 ` [PATCH 03/10] xfs: fix a sloppy memory handling bug in xfs_iroot_realloc Darrick J. Wong
2024-08-28 4:10 ` Christoph Hellwig
2024-08-27 23:34 ` [PATCH 04/10] xfs: replace shouty XFS_BM{BT,DR} macros Darrick J. Wong
2024-08-28 4:11 ` Christoph Hellwig
2024-08-29 2:00 ` Dave Chinner
2024-08-29 22:10 ` Darrick J. Wong
2024-08-30 3:43 ` Christoph Hellwig
2024-08-27 23:35 ` [PATCH 05/10] xfs: move the zero records logic into xfs_bmap_broot_space_calc Darrick J. Wong
2024-08-28 4:14 ` Christoph Hellwig
2024-08-29 1:15 ` Darrick J. Wong
2024-08-29 3:51 ` Christoph Hellwig
2024-08-29 2:05 ` Dave Chinner
2024-08-29 22:34 ` Darrick J. Wong
2024-08-27 23:35 ` [PATCH 06/10] xfs: refactor the allocation and freeing of incore inode fork btree roots Darrick J. Wong
2024-08-28 4:15 ` Christoph Hellwig
2024-08-28 4:17 ` Christoph Hellwig
2024-08-28 21:50 ` Darrick J. Wong
2024-08-27 23:35 ` [PATCH 07/10] xfs: refactor creation of bmap " Darrick J. Wong
2024-08-28 4:19 ` Christoph Hellwig
2024-08-29 2:13 ` Dave Chinner
2024-08-29 22:46 ` Darrick J. Wong
2024-08-27 23:35 ` [PATCH 08/10] xfs: hoist the code that moves the incore inode fork broot memory Darrick J. Wong
2024-08-28 4:20 ` Christoph Hellwig
2024-08-29 2:54 ` Dave Chinner
2024-08-29 23:35 ` Darrick J. Wong
2024-08-27 23:36 ` [PATCH 09/10] xfs: rearrange xfs_iroot_realloc a bit Darrick J. Wong
2024-08-28 4:21 ` Christoph Hellwig
2024-08-27 23:36 ` [PATCH 10/10] xfs: standardize the btree maxrecs function parameters Darrick J. Wong
2024-08-28 4:21 ` Christoph Hellwig
2024-08-27 23:45 ` [RFC PATCH] libxfs: compile with a C++ compiler Darrick J. Wong
2024-08-28 0:01 ` Sam James
2024-08-28 0:10 ` Sam James
2024-08-28 23:53 ` Darrick J. Wong [this message]
2024-08-29 0:17 ` Sam James
2024-08-29 1:30 ` Kees Cook
2024-08-28 4:25 ` Christoph Hellwig
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=20240828235341.GD6224@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=hch@lst.de \
--cc=kernel@mattwhitlock.name \
--cc=linux-xfs@vger.kernel.org \
--cc=sam@gentoo.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