IRC channel logs
2026-09-05.log
back to list of logs
<matrix_bridge><Jeremiah Orians> No, static binding but enabling build specialization <roconnor>Then I don't understand. If the artefact of a build dependency changes, it is natural to recompile the thing that depends on it. <stikonas>ideally maybe, but that will turn all your updates into constant world recompiles <matrix_bridge><Jeremiah Orians> No; because the only thing that changed was its build recipe; not its unique identifier <roconnor>But that implies the dependency changes out from underneath another package, which requiers dynamic linking. <matrix_bridge><Jeremiah Orians> No; it means that there can be a different recipe for the same output both of which may be acceptable inputs for other packages <roconnor>How do you relink the thing depending on the changed package without recompiling it? <matrix_bridge><Jeremiah Orians> You recompile or have a program that patches the binaries <matrix_bridge><Jeremiah Orians> Or just use the old version of the linked thing <roconnor>FWIW, there is a function in Nix call "replace runtime dependenies" that does this sort of binary patching. Of course it isn't quite the system you are imagining, but it gets you much of the way there. Usefull when bash has a critical bug. <roconnor>I was able to rebuild my system with an new bash in 5 minutes. <matrix_bridge><Jeremiah Orians> Well yes; nixos and guix are 97% of what I want and why I have not built up enough motivation to pursue the idea further <roconnor>Partial to Guix because of syntactic reasons? <matrix_bridge><Jeremiah Orians> Just found it a better match for my preferences. <matrix_bridge><Jeremiah Orians> Although they tend to depreciate various bits in my configuration every year. <matrix_bridge><Jeremiah Orians> Not that my system setups are that complicated <aggi>Andrius tikonas> eventually you hit a case where static binaries don't work well for some projects <aggi>Andrius tikonas> I think in live-bootstrap we first hit that point with python <aggi>i'll allow myself to elaborate a little further, mostly distribution-agnostic <aggi>since i've approached this from the tcc-toolchain support perspective, i did succeed with a python3.8.static compiled/linked with tcc here <aggi>sufficient to retain gentoo-portage tooling (which needs a notable amount of static modules linked) <aggi>in conjunction with cross-compilation the whole approach raised that many concerns, i rather abstain from gentoo-portage entirely <aggi>because i've had to fork and block gentoo-portage itself too for that reason <aggi>finally ~500ebuilds of precious foss C-software are waiting for re-integration/re-packaging here <aggi>notable efforts which i consider less concerning than the python-dependency <aggi>and i've concluded, the live-bootstrap configurator steps/ system itself seems a reasonable approach to maintain a bootstrappable distro <aggi>which intersects with cross-compilation concerns, considered less relevant if a distro can be fully bootstrapped natively <aggi>in the end, software such as python must remain fully optional <aggi>perl/autotools complicate the situation further, in the same context <aggi>yet looking at cdrtools for example (a highly relevant component for live-bootstrap imo), which seeked to resemble autotools behaviour in their build-system without perl/autotools <aggi>that's too indefinite pain, probably less then keeping a perl5.static for this <aggi>gladly i could confirm this, a most recent perl5.static version passing with tinycc here <aggi>for as long as i wouldn't need to cross-compile that one <aggi>another side-note, today some x86 NASM assembler booked arrived, which i'll need when seeing to syslinux/isolinux.bin shall comply with live-bootstrap criteria <aggi>so we can then cdrecord a live-bootstrap output onto cd-rw early during bootstrapping, without python/perl/autotools <aggi>the only piece there which would need perl, is isohybrid support for usb-flash, which can be moved into later stages of bootstrapping <aggi>because that's my argument, sorry to repeat it: of cause python/perl/... must be bootstrapped, but those should remain optional in the early stages <aggi>for make_bootable a linux2-tcc/busybox/tcc/vi x86_32-live.iso <aggi>a major burden with this one remaining, is year2038, another open task to prolong it's lifetime beyond <AwesomeAdam54321>More testing is very welcome, as I'm still in the middle of the build process <mihi>AwesomeAdam54321, I just fixed the CI configuration and it completed on GitHub actions without error <mihi>btw do you expect me to merge this in the current state, or do you rather try to get it upstreamed and in case anything isn't, merge it once the next Guile version is released? <xentrac>it's just that in this channel it's true a lot <mihi>I assume for getting it merged, they would want some things changed. E.g. not patching the stage2 via GNU patch, but by adding some macros in the file that expand to identity in the normal regenerate case and expand differently for bootstrapping... <mihi>btw AwesomeAdam54321, is there some discussion about upstreaming it anwywhere already? I checked guile-devel but did not find anything. <AwesomeAdam54321>I agree that changes are needed to make the bootstrap process nicer, and possibly handle the define* definition thing as well