Re: xfsprogs 7.1.0 LTINSTALL fix

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Jul 14, 2026 at 11:32:12PM +0000, Allen Hewes wrote:
> 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?

Correct.  It's surprising to me (but not really...) that it works on
Debian but apparently not Fedora.  But as your v2 patch shows, I think
your build root doesn't contain /usr/libexec/xfsprogs and apparently
mine does.

(Mine are /very/ sloppy)

--D

> > > 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