Re: xfsprogs 7.1.0 LTINSTALL fix

On Tue, 2026-07-14 at 13:45 -0700, Darrick J. Wong wrote:
> On Tue, Jul 14, 2026 at 05:18:37PM +0000, Allen Hewes wrote:
> > Hi!
> >
> > I am not a member of the list.
> >
> > I got local mock build error with xfsprogs 7.1.0:
> > Installing healer-install
> > ../install-sh -o root -g mock -m 755 -d /usr/libexec/xfsprogs
> > /bin/sh ../libtool --quiet --mode=install ../install-sh -o root -g
> > mock
> > -m 755 xfs_healer xfs_healer_start /usr/libexec/xfsprogs
> > Usage: /builddir/build/BUILD/xfsprogs-7.1.0-build/xfsprogs-
> > 7.1.0/libtool [OPTION]... [MODE-ARG]...
> > Try 'libtool --help' for more information.
> > libtool:   error: '/usr/libexec/xfsprogs' is not a directory
> > gmake[1]: *** [Makefile:72: install-healer] Error 1
> > make: *** [Makefile:135: healer-install] Error 2
> > error: Bad exit status from /var/tmp/rpm-tmp.YMwAaj (%install)
> >     Bad exit status from /var/tmp/rpm-tmp.YMwAaj (%install)
> >
> > RPM build errors:
> >
> > I tracked this down to a recent change
> > https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?id=79551362141a051faf9c3d504fe18ee34ca800f8
> > and then worked from there.
> >
> > It appears that LTINSTALL need a single target and not multiple
> > targets. Here's a patch that let me mock build xfsprogs 7.1.0:
>
> I guess that means libtool no longer just calls ../install-sh with
> whatever parameters it's given?  Or perhaps just yours?  On my
> system:
>
> $ libtool --version
> libtool (GNU libtool) 2.5.4 Debian-2.5.4-4
>
> It would be good to know if this is the result of gnu libtool
> changing
> their CLI in a newer version; or some other libtool clone is in use;
> or
> something else.
>

I am using the Fedora family. The specific mock lock was from fedora-
43-x86_64 on a Fedora 43 Workstation install.

I did check current Fedoras (43/44/rawhide) they are using the same
libtool version:
> libtool (GNU libtool) 2.5.4

There are different build bumps for Fedora 44 and Rawhide, but they are
the same libtool 2.5.4 version.

In my case, I think the BUILD_TARGETS got appended because configure
found HAVE_HEALER_START_DEPS = yes to cause the addition of
xfs_healer_start
(https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/tree/healer/Makefile#n44)

If HAVE_HEALER_START_DEPS = no, then BUILD_TARGETS would contain a
single target, xfs_healer? Right?

> >
> > diff -Nuarp xfsprogs-7.1.0.a/healer/Makefile xfsprogs-
> > 7.1.0.b/healer/Makefile
> > --- xfsprogs-7.1.0.a/healer/Makefile    2026-07-10
> > 07:06:28.000000000 -
> > 0400
> > +++ xfsprogs-7.1.0.b/healer/Makefile    2026-07-14
> > 13:08:18.106217736 -
> > 0400
> > @@ -69,7 +69,9 @@ install: $(INSTALL_HEALER)
> >
> >  install-healer: default
> >         $(INSTALL) -m 755 -d $(PKG_LIBEXEC_DIR)
> > -       $(LTINSTALL) -m 755 $(BUILD_TARGETS) $(PKG_LIBEXEC_DIR)
> > +       for f in $(BUILD_TARGETS); do \
> > +               $(LTINSTALL) -m 755 $$f $(PKG_LIBEXEC_DIR); \
> > +       done
> >
> >  install-systemd: default
> >         $(INSTALL) -m 755 -d $(SYSTEMD_SYSTEM_UNIT_DIR)
> >
> > I will send as an attachment.
> >
> > Thanks!
>
> Thank you for sending a patch, but it needs a proper Signed-off-by:
> tag
> before anyone can look at it.
>
> https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
>
> --D

Thanks for the tip. I sent a new patch in w/subject: [PATCH] xfsprogs:
healer: install targets one at a time

/allen