On Fri, Feb 12, 2021 at 01:55:06PM -0800, Markus Mayer wrote:
> On Fri, 12 Feb 2021 at 13:29, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> >
> > On 2/12/21 2:51 PM, Markus Mayer wrote:
> > >> To prevent issues when the ".o" extension appears in a directory path,
> > >> ensure that the ".o" -> ".lo" substitution is only performed for the
> > >> final file extension.
> > >
> > > If the subject should be "[PATCH] xfsprogs: ...", please let me know.
> >
> > Nah, that's fine, I noticed it.
> >
> > So did you have a path component that had ".o" in it that got substituted?
> > Is that what the bugfix is?
>
> Yes and yes.
>
> Specifically, I was asked to name the build directory in our build
> system "workspace.o" (or something else ending in .o) because that
> causes the automated backup to skip backing up temporary build
> directories, which is what we want. There is an existing exclusion
> pattern that skips .o files during backup runs, and they didn't want
> to create specialized rules for different projects. Hence the request
> for the oddly named directory to make it match the existing pattern.
>
> We also have a symlink without the ".o" extension (workspace ->
> workspace.o) which is commonly used to access the work space, but
> symlinks frequently get expanded when scripts run. In the end, the
> xfsprogs build system saw the full path without the symlink
> (".../workspace.o/.../xfsprogs-5.8.0/...") and started substituting
> workspace.o with workspace.lo. And then the build died.
>
> Like this:
>
> >>> xfsprogs 5.8.0 Building
> PATH="/local/users/jenkins/workspace.o/buildroot_linux-5.4_llvm/output/arm64/host/bin:/local/users/jenkins/workspace.o/buildroot_linux-5.4_llvm/output/arm64/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
> /usr/bin/make -j33 -C
> /local/users/jenkins/workspace.o/buildroot_linux-5.4_llvm/output/arm64/build/xfsprogs-5.8.0/
> [HEADERS] include
> [HEADERS] libxfs
> Building include
> [LN] disk
> make[3]: Nothing to be done for 'include'.
> Building libfrog
> [CC] gen_crc32table
> [GENERATE] crc32table.h
> make[4]: *** No rule to make target
> '/local/users/jenkins/workspace.lo/buildroot_linux-5.4_llvm/output/arm64/target/usr/include/uuid/uuid.h',
> needed by 'bitmap.lo'. Stop.
So there's a rule like this generated:
bitmap.lo: bitmap.c ../include/xfs.h ../include/xfs/linux.h \
../include/xfs/xfs_types.h ../include/xfs/xfs_fs_compat.h \
../include/xfs/xfs_fs.h ../include/platform_defs.h avl64.h \
../include/list.h bitmap.h
The sed expression is:
$(SED) -e 's,^\([^:]*\)\.o,\1.lo,'
Which means it is supposed to match from the start of line to a ".o",
and store everything up to the ".o" in register 1.
And the problem is that it is matching a ".o" in the middle of a
string.
So existing behaviour:
$ echo "foo.o/bitmap.o: bitmap.c ../include/xfs.h ../include/xfs/linux.h" | sed -e 's,^\([^:]*\)\.o,\1.lo,'
foo.o/bitmap.lo: bitmap.c ../include/xfs.h ../include/xfs/linux.h
$
Looks correct until the dependency line is split and the first entry
in the split line is something like "foo.o/uuid.h"
Your modified version:
$ echo "bitmap.o: bitmap.c ../include/xfs.h ../include/xfs/linux.h" | sed -e 's,^\([^:]*\)\.o$$,\1.lo,'
bitmap.o: bitmap.c ../include/xfs.h ../include/xfs/linux.h
$
Doesn't work for the case we actually need the substitution for.
So, really, I think we need to match against the full target
specification rather than just ".o".
Something like
$SED -e 's,^\([^:]*\)\.o: ,\1.lo: ,'
$ echo "foo.o/bitmap: bitmap.c ../include/xfs.h ../include/xfs/linux.h" | sed -e 's,^\([^:]*\)\.o: ,\1.lo: ,'
foo.o/bitmap: bitmap.c ../include/xfs.h ../include/xfs/linux.h
$ echo "foo.o/bitmap.o: bitmap.c ../include/xfs.h ../include/xfs/linux.h" | sed -e 's,^\([^:]*\)\.o: ,\1.lo: ,'
foo.o/bitmap.lo: bitmap.c ../include/xfs.h ../include/xfs/linux.h
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
