IRC channel logs
2024-02-16.log
back to list of logs
<fossy>Googulator: i can confirm the builder-hex0 patch allowed my build to get past the point where it was before <fossy>on one of my bare metal machiens <fossy>however i have another "problem" (kind of); builder-hex0 seems to print the content of all files to my screen while booting? i'm not sure if this is new or a change i missed or something, but we need a switch to disable it if it is <fossy>problem 1 with that: it makes srcfs creation reallllly slow on some systems because of console scrolling <fossy>problem 2: when it gets to binary files my machine starts incessently beeping because of beep ASCII code being repeatedly printed to console LOL <Googulator>fossy: I didn't implement such a change, something else is likely going on <Googulator>if that write wrongly targets open file numbers <=2, it will write to the screen instead of the memory FS <Googulator>BTW, yes, I am planning a feature to print file contents to the screen, but it's gonna be opt-in, and it also will specifically exclude compressed files <oriansj>deesix: thinking further on the live-bootstrap tarball mirror problem; we can easily setup our own server for distributing copies and IPFS/GNUnet/bittorrent can be used as a fallback. With sha256sum being used in the short term to secure the contents but we may wish to think about multi-signatures and things like sig-store and Crev. <fossy>Guest991: we discussed your problem yesterday here in this channel and there is not really a solution currently possible <fossy>to be very clear: your hardware does not currently support bare metal bootstrap <stikonas>Guest991: yes, you will have to use stage0-uefi route... <mid-kid>Does anyone happen to know how I can figure out where gcc loads its default specs files from <mid-kid>Bootstrapping multilib is always a major pain <oriansj>mid-kid: well, the source code always tells the truth; the documentation sometimes lies and memories can be faulty. <oriansj>although the source code can present itself in misleading forms. <stikonas>for file access usually strace'ing gives a quick answer <oriansj>which can usually be combined with grep -iR $filename to find where in the source it is <oriansj>then you can probably know which flags/environment variables may impact that <Googulator>YES! First successful build of the new kernel in qemu! <matrix_bridge><Andrius Štikonas> Googulator: can you update changelog too for stage0-posix <Googulator>stikonas: should we have a separate entry for "Fix handling of compressed and uncompressed sizes in the aforementioned unxz program" after "Add a fully functional unxz program"? <Googulator>(unxz is new in main / will be new in the next release of stage0-posix) <mid-kid>oriansj: I ended up just grabbing a copy of LFS 9.0, lol <mid-kid>It's $(dirname $(gcc --print-libgcc-file-name))/specs <mid-kid>and it's additive on top of the baked-in specs <mid-kid>I wish this was documented somewhere before LFS 9.0 disappears from the website though <matrix_bridge><Andrius Štikonas> mid-kid: do we need multilib to switch to 64 bits? <matrix_bridge><Andrius Štikonas> So it might just work to replace gcc with x86 to x86_64 crosscompiler <mid-kid>no, we don't need multilib to simply "switch" to 64 bits <mid-kid>LFS chapters 5 and 6 deal with making a cross-compiler and cross-compiling glibc and a bunch of tools which is good enough <mid-kid>good enough to switch to 64 bits I mean <mid-kid>(it works if you follow the instructions verbatim) <mid-kid>problem is that gentoo's default setup is multilib <mid-kid>and to build a multilib gcc you need glibc built as both 32-bit and 64-bit <mid-kid>but to build glibc as 32-bit you need a 32-bit libgcc <mid-kid>and to build a 32-bit libgcc you need the 32-bit glibc headers and a 32-bit gcc <mid-kid>and to build a 32-bit libgcc with unwind support you need a 32-bit libstdc++ <mid-kid>Basically I've been wrestling with the build systems to see if I could manage a shortcut through this crap <mid-kid>I could've sworn I had hacked my way through this before without too much of an issue <mid-kid>s/too much of an issue/too many manual steps/ <mid-kid>which is just not something I wanna mess with again right now <mid-kid>So instead I've been messing with leveraging portage's capabilities to build a cross-compiler <mid-kid>Defeating the point of using LFS as an intermediate step in the first place <matrix_bridge><Andrius Štikonas> If you can get portage to do that, might be easier to automate... <mid-kid>Yeah, I just thought the LFS instructions would be easier to mangle to also cross-compile to other arches like aarch64 instead of just x86_64. <mid-kid>Might be able to pull something together with just portage but eh, we'll see <mid-kid>So, portage has this feature where you can pass extra flags to `make` using EXTRA_EMAKE it does so by calling "make ${EXTRA_EMAKE}", relying on variable expansion to pass multiple flags. I'm trying to set EXTRA_EMAKE="TARGET-libcc1='all libsuffix=../lib64'", but it always splits at the space, so TARGET-libcc1 ends up being "'all", instead of the whole thing. <mid-kid>Is there a way to somehow escape the space to have it be expanded by make only? <mid-kid>This is a bash variable inherited from the environment, idk if that matters <mid-kid>Apparently I can do EXTRA_EMAKE="TARGET-libcc1=all TARGET-libcc1+=libsuffix=../lib64". This feels awful :) <mid-kid>And it doesn't get passed during install ._. <oriansj>\ can be used to escape and \\ for double nested escapes <oriansj>actually EXTRA_EMAKE='TARGET-libcc1=all libsuffix=../lib64' should be the correct thing as you want the space to be used to separate the two environmental variables <mid-kid>no dice either, you can try it yourself by `printf '%s\n' ${EXTRA_EMAKE}` <mid-kid>oriansj: I don't want to separate them, I want the contents of TARGET-libcc1 to be, verbatim "all libsuffix=../lib64" <mid-kid>so the latter variable gets passed to the subdir build <mid-kid>bleh, this method didn't work anyway <oriansj>so you want it to resolve to be the command: make 'TARGET-libcc1=all libsuffix=../lib64' ??? I don't think the makefile is likely to have such a named target <oriansj>but make TARGET-libcc1=all is entirely possible and libsuffix=../lib64 would be a valid environmental variable to set <oriansj>and the command make all with the environmental variables TARGET-libcc1=all libsuffix=../lib64 set is also possible. <mid-kid>oriansj: the `make` command-line doesn't just accept targets, but also variable overrides <mid-kid>the makefile has a variable called TARGET-libcc1 which isn't inherited from the environment, that I want to replace <mid-kid>The ultimate goal is replacing the libsuffix variable in a subdirectory makefile <mid-kid>but it seems I cannot use TARGET-libcc1 for this for other reasons <mid-kid>What worked is something significantly worse: EXTRA_EMAKE="MAKE=make MAKE+=libsuffix=../lib64" <Googulator>make sure you're reviewing the version with e24c071856f657f892b4888347a2fbdf97771a7b as the top commit, as I've made a bit of a mess with quite a few force pushes before I arrived at that version <stikonas>though this is kernel, so let's wait for fossy's review too <stikonas>hopefully next time upgrade will be easier <Googulator>even this one actually had some incompatibilities with our toolchain <Googulator>but I had to disable the bfq scheduler in config, because it caused a weird link error <Googulator>(luckily cfq builds just fine, and that's what we actually use by default) <Googulator>also, it's .336, the very last patchlevel released <Googulator>IIRC with 4.9, a newer patchlevel was prevented by the old binutils <oriansj>and Googulator; thank you for letting me know about the github pull request. (I virtually never look and github refuses to email me for some stupid reason) <stikonas>it does not fully implement "open" modes but should work better than what we currently have on UEFI