Hi Liam,
On Thu, 30 Jan 2025 at 16:17, Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote:
* Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> [250130 09:25]:
On Thu, 30 Jan 2025 at 15:06, Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote:
it is to get m68k to build, you should probably know how to read a
makefile.
Like all other kernel cross-compilation? Usually you don't even have
to know where your cross-compiler is living:
make ARCH=m68k
Ignoring that I had to make a config - which asked challenging
questions...
make ARCH=m68k defconfig
That also prompts, defoldconfig did not.
Hmm, using a defconfig should never ask for questions.
Perhaps this might happen if it has an option enabled that depends on
specific compiler support?
And ignoring the steps to get m68k compiler...
apt install gcc-m68k-linux-gnu?
There are a few compilers, multilib or such? I've had issues with
getting all the archs working for cross compile on the same machine
(arm, arm64, riscv, m68k, ppc, ppc64, parisc).
I have installed all of the above (and more) from Ubuntu
(except for parisc, as Ubuntu does not have it), and more
from https://www.kernel.org/pub/tools/crosstool/.
All of them should work fine (for building kernels).
When trying the above, and ignoring failures due to missing packages
on my host:
- there are several weird build errors,
- this doesn't play well with O=,
- lots of scary warnings when building for 32-bit,
- ...
In file included from ./include/linux/sched.h:12,
from arch/m68k/kernel/asm-offsets.c:15:
./arch/m68k/include/asm/current.h:7:30: error: invalid register name for ‘current’
7 | register struct task_struct *current __asm__("%a2");
Which compiler are you using?
I've had a hard time getting m68k to boot in qemu because of the lack of
userspace. I use m68k for nommu testing, but have a hard time getting
the buildroot to work correctly to build what I need.
I only do m68k with MMU, and use Debian (ports) userland.
Perhaps https://landley.net/toybox/ might give you a nommu userland.
More importantly, I think I get your point, you think that the testing
should be integrated and complain if it's broken - at least by bots. I
don't think this is practical in all cases, unfortunately.
Exactly:
- (cross)building kernel module tests is easy, and included in a
kernel build, so build failures are detected early.
- (cross)building the userland testing tools is cumbersome.
So there's an opportunity for improvement...
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
