On Mon, Jun 10, 2024 at 9:34 PM John Hubbard <jhubbard@xxxxxxxxxx> wrote:
On 6/10/24 9:21 PM, Jeff Xu wrote:
Hi
On Fri, Jun 7, 2024 at 7:10 PM John Hubbard <jhubbard@xxxxxxxxxx> wrote:
What is the "official" way to build selftests/mm ?
Eventually, once the build succeeds on a sufficiently old distro, the
idea is to delete $(KHDR_INCLUDES) from the selftests/mm build, and then
after that, from selftests/lib.mk and all of the other selftest builds.
For now, this series merely achieves a clean build of selftests/mm on a
not-so-old distro: Ubuntu 23.04:
1. Add __NR_mseal.
2. Add fs.h, taken as usual from a snapshot of ./usr/include/linux/fs.h
after running "make headers". This is how we have agreed to do this sort
of thing, see [1].
From Documentation/dev-tools/kselftest.rst, it is:
$ make headers
$ make -C tools/testing/selftests
I tried a few ways, but it never worked, i.e. due to head missing.
You are correct. Today's rules require "make headers" first. But
I'm working on getting rid of that requirement, because it causes
problems for some people and situations.
(Even worse is the follow-up rule, in today's documentation,
that tells us to *run* the selftests from within Make! This
is just madness.
That is hilarious! :)
Because the tests need to run as root inBut I don't want to install random packages if possible.
many cases. And Make will try to rebuild if necessary...thus
filling your tree full of root-owned files...but that's for
another time.)
1>
cd tools/testing/selftests/mm
make
migration.c:10:10: fatal error: numa.h: No such file or directory
10 | #include <numa.h>
| ^~~~~~~~
compilation terminated.
2>
make headers
make -C tools/testing/selftests
make[1]: Entering directory
'/usr/local/google/home/jeffxu/mm/tools/testing/selftests/mm'
CC migration
migration.c:10:10: fatal error: numa.h: No such file or directory
10 | #include <numa.h>
Well, actually, for these, one should install libnuma-dev and
numactl (those are Ubuntu package names. Arch Linux would be:
numactl).
I think. The idea is: use system headers if they are there, and
local kernel tree header files if the items are so new that they
haven't made it to $OLDEST_DISTO_REASONABLE.
Something like that.
Can makefile rule continue to the next target in case of failure though ?
right now it stopped at migration.c , if it continues to the next target, then
I don't need to use gcc to manually build mseal_test.