Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could not build Linux kernel #118

Open
tpimh opened this issue Jun 12, 2017 · 10 comments
Open

Could not build Linux kernel #118

tpimh opened this issue Jun 12, 2017 · 10 comments

Comments

@tpimh
Copy link

tpimh commented Jun 12, 2017

I guess this is a very complex issue because the kernel has a lot of Makefiles and uses a lot of specific features that may not be supported.
Now if I run kati in the kernel source tree, I get this:

./scripts/Makefile.build:423: kati doesn't support .PRECIOUS
./arch/x86/entry/syscalls/Makefile:49: Automatic variable `$?' isn't supported yet
*** [archheaders] Error 1

It is at least two features that should be supported in order to build Linux, but I believe there are more.

@danw
Copy link
Collaborator

danw commented Jun 12, 2017

Are you attempting to build in ninja mode, or directly with ckati? (I'm assuming directly with ckati, since I doubt you'd get very far otherwise -- ninja mode doesn't support recursive make)

For Android we've really only used ckati in ninja mode, where PRECIOUS is more-or-less default, and $? can't be supported (at least without some sort of command wrapper)

@tpimh
Copy link
Author

tpimh commented Jun 12, 2017

Yes, I'm trying directly with ckati. I'm aware of the lack of recursive make support in ninja mode. I guess the kernel can only be compiled with GNU Make for now.

@maurossi
Copy link

Hi,
Is there any news on this?
I'm trying to optimize the kernel build in android-x86 project, but at the -j for parallel jobs is the only optimization I can get.
Is there a way to invoke ckati from inside an mk task like [1] ?
Thanks for any info

[1] http://git.osdn.net/view?p=android-x86/build.git;a=blob;f=core/tasks/kernel.mk;h=c7b5e7a9700859166c2497757c0d0093e8b83fc3;hb=refs/heads/nougat-x86

@DelilahHoare
Copy link
Contributor

My fork https://github.com/DelilahHoare/kati is able to make defconfig and compile the kernel. It's a bit rough. I sent in my first couple simple changes as PRs already; if they ever get merged I'll try to polish the rest of the changes and make more PRs.

I haven't benchmarked it but I would expect this to be slower than GNU make. I ignored ninja mode. All I wanted was a drop-in replacement for GNU make that can compile linux, and now the world has that.

@metti
Copy link
Collaborator

metti commented Mar 9, 2022

That is very interesting and I would be interested in working with you on this! In particular, I am interested in the Ninja mode as well!

@tpimh
Copy link
Author

tpimh commented Mar 9, 2022

@DelilahHoare Thank you very much for your effort! I will definitely test your code and hope it will be merged!

@Colecf
Copy link
Collaborator

Colecf commented Nov 28, 2022

What's the motivation for building the kernel with kati? Especially if you're not interested in the ninja mode, as that's kati's main benefit.

@tpimh
Copy link
Author

tpimh commented Nov 29, 2022

What's the motivation for building the kernel with kati? Especially if you're not interested in the ninja mode, as that's kati's main benefit.

I'm interested in both ninja mode and direct Makefile interpretation. The speed is not my goal, at the time I was researching the practical possibility to build the Linux kernel without using the GNU tools. It turned out, that the only Makefile interpreter sufficient to build Linux is GNU Make.

@tpimh
Copy link
Author

tpimh commented Nov 29, 2022

Looks like #242 implemented support for $?, so I will test again and check if it still fails, then update the issue.

@tpimh
Copy link
Author

tpimh commented Jan 5, 2023

Building Linux 6.1.3 now. Still getting lots of kati doesn't support .SECONDARY warnings from this line. For the future versions of Linux, .NOTINTERMEDIATE would be the preferred option.

On the bright side, defconfig target was a success. The first obstacle was not building ./tools/objtool/objtool, but it was successfully built by just using this Makefile directly with just a couple minor fixes.

The next obstacle is No rule to make target 'arch/x86/entry/vdso/vdso-image-64.o', needed by 'arch/x86/entry/vdso/built-in.a'. and subsequent similar message about vdso-image-32.o, and this is where I currently gave up. I didn't investigate this issue much, but I will be revisiting it at some point in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants