[LTP] [PATCH] configure.ac: fix mount_attr detection

Li Wang liwang@redhat.com
Fri Mar 10 07:25:42 CET 2023


On Mon, Feb 27, 2023 at 7:26 PM Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> > Commit b857f8723f30a4b9554bf6b0ff8fa52fd07e8b60 tried to fix build with
> > latest glibc which provides mount_attr in sys/mount.h. Unfortunately,
> > the following build failure is still raised because sys/mount is now
> > unconditionally included in include/lapi/fsmount.h:
> >
> > In file included from fsconfig01.c:9:
> > ../../../../include/lapi/fsmount.h:55:8: error: redefinition of 'struct
> mount_attr'
> >    55 | struct mount_attr {
> >       |        ^~~~~~~~~~
> > In file included from ../../../../include/lapi/fsmount.h:14:
> >
> /home/autobuild/autobuild/instance-4/output-1/host/armeb-buildroot-linux-gnueabi/sysroot/usr/include/sys/mount.h:210:8:
> note: originally defined here
> >   210 | struct mount_attr
> >       |        ^~~~~~~~~~
> >
> > Fixes:
> >  -
> http://autobuild.buildroot.org/results/4dbb72e1bf081afd3cd944571b9beeefc7608865
> >
> > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> > ---
> >  configure.ac | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index c2b0f48e7..a6d8ac826 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -225,10 +225,10 @@ AC_CHECK_TYPES([struct __kernel_old_timeval,
> struct __kernel_old_timespec, struc
> >
> >  AC_CHECK_TYPES([struct futex_waitv],,,[#include <linux/futex.h>])
> >  AC_CHECK_TYPES([struct mount_attr],,,[
> > -#ifdef HAVE_LINUX_MOUNT_H
> > -# include <linux/mount.h>
> > -#else
> > +#ifdef HAVE_MOUNT_SETATTR
> >  # include <sys/mount.h>
> > +#elif HAVE_LINUX_MOUNT_H
> > +# include <linux/mount.h>
> >  #endif
> >  ])
>
> I wonder if we can get this whole mess of two different fallback headers
> simplified. Looking at the glibc implementation it seems to include
> "linux/mount.h" if it does exist. So most reasonable solution would do
> the same I guess which we did before the commit you reference.
>

This is indeed correct if only face the latest Glibc, but that might have
problems when building LTP on a middle version of Glibc/Kernel-headers.
The bug I mentioned in the last email was fixed since glibc-2.37~426.

@Fabrice, what kind of version of Glibc/Kernel-headers do you use? and
which platform?

Btw, this patch builds LTP successfully in CI:
  - https://github.com/wangli5665/ltp/actions/runs/4380739470
And I manually tried with fedora-rawhide/fedora34/35/37/38 all looks good.

Maybe we can just apply this patch to keep everything with no big changes.

@Cyril, Petr, what do you think?


-- 
Regards,
Li Wang


More information about the ltp mailing list