Created attachment 706458 [details] dev-util/kbuild-0.1.9998.3407 build.log (gzip) Hello, After I met the issue reported in bug #787572, I tried to recompile dev-util/kbuild (current version 0.1.9998.3407), however it fails to compile with following messages (full log in attachment): ================================================================ The failing command: @kmk_builtin_redirect -rti /var/tmp/portage/dev-util/kbuild-0.1.9998.3407/work/kbuild-0.1.9998.3407/out/linux.amd64/release/obj/kUtil/kUtil.a.ar-script -- ar -M kmk: *** [/var/tmp/portage/dev-util/kbuild-0.1.9998.3407/work/kbuild-0.1.9998.3407/out/linux.amd64/release/obj/kUtil/kUtil.a] Deleting file '/var/tmp/portage/dev-util/kbuild-0.1.9998.3407/work/kbuild-0.1.9998.3407/out/linux.amd64/release/obj/kUtil/kUtil.a.ar-script' kBuild: Linking kUtil kmk: *** [/var/tmp/portage/dev-util/kbuild-0.1.9998.3407/work/kbuild-0.1.9998.3407/kBuild/footer-pass2-compiling-targets.kmk:552: /var/tmp/portage/dev-util/kbuild-0.1.9998.3407/work/kbuild-0.1.9998.3407/out/linux.amd64/release/obj/kUtil/kUtil.a] Segmentation fault kmk: *** Waiting for unfinished jobs.... ../.. kmk: *** Exiting with status 2 ================================================================ However, no dump core which is unexpected ('kernel.core_pattern = /tmp/core_%e_%t_%p' in sysctl). Maybe it is related to GCC 11.1, since I recently switched to this version. Best regards,
Created attachment 706461 [details] emerge --info dev-util/kbuild
As mentioned, I think now bug #787572 is related to this issue.
PROBLEM: I am stuck on the same exact issue. It is a pre-requisite for virtualbox and has stopped me dead. To be clear, I speak exactly of this being the bug: @kmk_builtin_redirect -rti /var/tmp/portage/dev-util/kbuild-0.1.9998.3407/work/kbuild-0.1.9998.3407/out/linux.amd64/release/obj/kUtil/kUtil.a.ar-script -- ar -M kmk: *** [/var/tmp/portage/dev-util/kbuild-0.1.9998.3407/work/kbuild-0.1.9998.3407/out/linux.amd64/release/obj/kUtil/kUtil.a] Deleting file '/var/tmp/portage/dev-util/kbuild-0.1.9998.3407/work/kbuild-0.1.9998.3407/out/linux.amd64/release/obj/kUtil/kUtil.a.ar-script' kBuild: Linking kUtil kmk: *** [/var/tmp/portage/dev-util/kbuild-0.1.9998.3407/work/kbuild-0.1.9998.3407/kBuild/footer-pass2-compiling-targets.kmk:552: /var/tmp/portage/dev-util/kbuild-0.1.9998.3407/work/kbuild-0.1.9998.3407/out/linux.amd64/release/obj/kUtil/kUtil.a] Segmentation fault MY NOTES: I have spent about 3 hours on this debugging with no fix, and two different but similar systems, and determined that something is very wrong with the package. I am running GCC 10.3.0-r1 in Hardened mode on AMD64 Ryzen1. (I have also tried manually executing the commands that fail and digging around the source code to uncover why, and the bug persists) Reading the ebuild leads me to determine something is highly non-standard about the normal way this package interacts with the AR implementation (variable tc-getAR used) and the LD Linker (relevant patches). I also believe pthreads could be relevant because I get this message when the install phase is initially launched as well: kmk: Threads disabled (LD_PRELOAD) (and if you dig this wording up in the kmk source, its part of the last clause of an elseif that means something unusual was detected) To make things worse, the faulting "kUtil.a.ar-script" file gets auto-deleted by a mechanism in KMK. There may be a way in kmk-speak to mark it "precious" to persist, or compile that deletion out. Then examine what this linker script actually says to cause the segfault. The rest is beyond me. (I have also tried to build a whole different kbuild-0.1.9998.3437 revision I found sitting on a gentoo package server somewhere, and that one has even worse problems.) Please help - I need VirtualBox. and Thank you.
Update: Ive given up on this revision of Kbuild, I've come to the conclusion .3407 is not viable at all. Most of the "kmk_builtin_redirect" kmk built-in functions are segfaulting. Good News: Kbuild .3499 worked perfectly. With it working, I ended up being able to get virtualbox working. It just required emerge =dev-util/kbuild-9999 (unmasking ~amd64 and using SVN to download latest revision 3499 from the SVN trunk) Kbuild should be updated to stabilize the -9999 file into a new 9998.3499 ebuild. (also FYI bug #787572 has more gory details relevant to this kbuild/virtualbox saga)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=68e5e01daa13f366aa7faccc63c10575e6f972e9 commit 68e5e01daa13f366aa7faccc63c10575e6f972e9 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2021-08-25 08:36:15 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2021-08-25 08:39:30 +0000 dev-util/kbuild: Bump to version 0.1.9998.3499 Thanks-to: <genBTC@gmx.com> Bug: https://bugs.gentoo.org/787572 Bug: https://bugs.gentoo.org/788691 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> dev-util/kbuild/Manifest | 1 + .../kbuild/files/kbuild-0.1.9998.3499-gold.patch | 15 +++++ ...98.3499-kash-no_separate_parser_allocator.patch | 11 ++++ dev-util/kbuild/kbuild-0.1.9998.3499.ebuild | 75 ++++++++++++++++++++++ 4 files changed, 102 insertions(+)
Please give dev-util/kbuild-0.1.9998.3499 a try and report back your results.
Created attachment 751178 [details] dev-util/kbuild-0.1.9998.3499 results - still broken
(In reply to Lars Wendler (Polynomial-C) from comment #6) > Please give dev-util/kbuild-0.1.9998.3499 a try and report back your results. Sorry for taking so long to get back to you but this is still reporting a segmentation fault in the final stages of linking Kbuild. (Results unchanged) I have included an attachment.
(In reply to genBTC from comment #8) > (In reply to Lars Wendler (Polynomial-C) from comment #6) > > Please give dev-util/kbuild-0.1.9998.3499 a try and report back your results. > I have done some more testing and conclude the bug comes from KBUILD_SVN_REV Package 3499 and package 9999 seem identical, but 3499 does not work (same error), even after your fix kindly repackaged 9999 into the 3499 tar.gz as I requested. It appears that deleting the KBUILD_SVN_REV line from the 3499 ebuild (so it never creates a SvnInfo.kmk file) allows the build to complete. Since this line of code is not-applicable to the 9999, that is why it works. I can read Config.kmk and notice there is some logic related to KBUILD_SVN_REV and in the cases where this SvnInfo.kmk file is missing, it sets KBUILD_SVN_REV := 0 and KBUILD_SVN_URL := /dev/null . Then this variable is passed to the compilation process as -DKBUILD_SVN_REV=0. So THIS ALL WORKS ----------------- The binary compiles and functions. (However the version being set to 0 in the resulting binary is problematic for virtualbox builds because they do a strict version check, and 0 fails the check) What DOESNT WORK: ---------------- is when SvnInfo.kmk exists, with KBUILD_SVN_REV := 3499 and -DKBUILD_SVN_REV=3499 is passed. Then the link error + segfault happens. This is the only reason we are hitting bugs. It is unclear how this trivial version number is so impactful as to brick the entire process. Please check the code. Thank you
(In reply to genBTC from comment #9) > I have done some more testing and conclude the bug comes from KBUILD_SVN_REV I made a slight error in the last post. the -D KBUILD_SVN_REV define is 1, never 3499. Doesnt matter either way, I uncovered the success to all my problems: Step 1) kbuild-0.1.9998.3499.ebuild @ line 54 = Remove this KBUILD_SVN_REV > SvnInfo.kmk entirely. Step 2) ebuild kbuild-0.1.9998.3499.ebuild compile (stop halfway through) Step 3) edit the file: /var/tmp/portage/dev-util/kbuild-0.1.9998.3499/work/kbuild-0.1.9998.3499/out/linux.amd64/release/obj/SvnInfo.kmk Change: KBUILD_SVN_REV := 0 To new: KBUILD_SVN_REV := 3499 Step 4) ebuild kbuild-0.1.9998.3499.ebuild install Doing this process any other way other than editing the SvnInfo.kmk file in the output obj directory will result either in A) linking kUtil segfault or B) incorrect version number 0 which leads virtualbox Config.kmk to die because of failed version check.
(In reply to genBTC from comment #10) For clarity, "stop halfway through" meant I had to run the individual stages seperately. Pause after completing "Compile" stage, so I can edit the SvnInfo.kmk file that gets produced in the out / obj dir, change 0 to 3499, then run Install phase seperately. I am not sure how this can be scripted into the ebuild.
Created attachment 751216 [details] dev-util/kbuild-0.1.9998.3499 success - see Comment#10 Build completes properly when out/linux.amd64/release/obj/SvnInfo.kmk KBUILD_SVN_REV is changed from 0 to 3499 halfway between Compile and Install phases. Attempting to use the ebuild to create a SvnInfo.kmk in the root dir right from the start fails. This file never actually gets re-created in the output dir.
I have some news. I discovered using the linux-hardened (anthraxx) kernel patches is what results in this build breakage. This in turn affects virtualbox. I have confirmed this on my own box, even narrowing it down to a specific "mm" patch in it. the "hardened1" string in OP's emerge --info kernel likely indicates that they are using this patch as well. So far this is the only bug i've experienced that pinpointed back to these well accepted albeit 3rd party hardened patchsets. Sorry for the confusion hopefully OP can respond: TLDR: OP: are you using -hardened1 kernel patch ? and if so, make a kernel without that, try Kbuild and report back.
(In reply to genBTC from comment #13) > I have some news. I discovered using the linux-hardened (anthraxx) kernel > patches is what results in this build breakage. This in turn affects > virtualbox. > I have confirmed this on my own box, even narrowing it down to a specific > "mm" patch in it. > ... so which patch is it? Please link to it.
(In reply to Sam James from comment #14) > (In reply to genBTC from comment #13) > > I have some news. I discovered using the linux-hardened (anthraxx) kernel > > patches is what results in this build breakage. This in turn affects > > virtualbox. > > I have confirmed this on my own box, even narrowing it down to a specific > > "mm" patch in it. > > > > ... so which patch is it? Please link to it. Those patches, Sam: https://github.com/anthraxx/linux-hardened/releases Hence the name "anthraxx" and the repository linux-hardened, but I agree an explicit link is better. It’s been a while I did not try again, just right now I fall again in the same issue and report than first comment. I can’t test currently yet with a Gentoo flavor kernel (same than my kernel without anthraxx’s patches), I’ll try to keep update soon enough. Best regards,
(In reply to Thibaud CANALE from comment #15) > (In reply to Sam James from comment #14) > > (In reply to genBTC from comment #13) > > > I have some news. I discovered using the linux-hardened (anthraxx) kernel > > > patches is what results in this build breakage. This in turn affects > > > virtualbox. > > > I have confirmed this on my own box, even narrowing it down to a specific > > > "mm" patch in it. > > > > > > > ... so which patch is it? Please link to it. > > Those patches, Sam: > https://github.com/anthraxx/linux-hardened/releases > > Hence the name "anthraxx" and the repository linux-hardened, but I agree an > explicit link is better. But if an explicit patch is identified (it sounds like a specific commit from that repo is known to be the problem), we need to know which one. Thank you!
I forgot to mention it, I am currently using the Linux 6.0.15 with its related patch "6.0.15-hardened1", and with some very few patches to work with Gentoo: https://github.com/anthraxx/linux-hardened/releases/tag/6.0.15-hardened1 PS: wow you are so fast, Sam, you were able to response before I could even amend my own comment x)
Hello, I confirm atom 'dev-util/kbuild-0.1.9998.3407' compiles entirely without those "hardened1" patches. I tested on running kernel from sources 'sys-kernel/gentoo-sources:6.0.17'. With some diggings about "hardened1" 6.0.16 patch sets, I was able to find there is 104 commits on top on upstream Torvalds’ linux commit "Linux 6.0.16" 29e1bc6a55debd187afb6ec2e49beb7e57102b0a. https://github.com/anthraxx/linux-hardened/compare/29e1bc6a55debd187afb6ec2e49beb7e57102b0a...6.0.16-hardened1 Now I don’t know how to find the root issue, I don’t know which "mm" commits genBTC is referencing to, but I guess it’s one of the 104 commits mentioned above. Best regards,
EDIT: I just understood you were asking about which specific anthraxx’s commit you were asking, Sam. Sorry I misunderstood the question. I hope genBTC can answer.
Created attachment 847776 [details, diff] hardened1 patches that trigger BUG you remove these files changed from your hardened1 patchset, the bug does not trigger. The file I posted went to version 5.15.85. It should be possible to just cut and paste what you see here out of the original -hardened1.patch, for any other version. Beyond that, I dont know why. Reverse Patch The files modified are: arch/x86/entry/vdso/vma.c arch/x86/include/asm/elf.h arch/x86/kernel/process.c arch/x86/kernel/sys_x86_64.c
(In reply to genBTC from comment #20) > Created attachment 847776 [details, diff] [details, diff] > hardened1 patches that trigger BUG > > you remove these files changed from your hardened1 patchset, the bug does > not trigger. The file I posted went to version 5.15.85. It should be > possible to just cut and paste what you see here out of the original > -hardened1.patch, for any other version. Beyond that, I dont know why. > > Reverse Patch > > The files modified are: > arch/x86/entry/vdso/vma.c > arch/x86/include/asm/elf.h > arch/x86/kernel/process.c > arch/x86/kernel/sys_x86_64.c Can you identify these in the form of a commit on the github? You can probably figure it out by looking at the recentr changes to those files. Anyway, tbh, I very much suspect this is a bug in kbuild and these patches just affect management enough to expose it. You should ask anthraxx, the author of those patches, to look into it and see if they can reproduce.
I installed 6.0.15 with the patch in a VM and I reproduced the issue. I don't know why it happens, but kmk crashes with SIGSEGV and refuses to dump core. When I have the time I'll attempt to look into the sources and see if I can figure it out, but until then I suggest either asking upstream if they have any idea or isolating the exact patch that causes this and removing it. What's worse, even if kmk is prebuilt w/o the patch, it still crashes when trying to build both virtualbox and virtualbox-guest-additions, so it's unusable.
