<gforce_de1977>(it shows, that peak RAM usage seems to be 944 Megabytes max on i386/x86) <gforce_de1977>(however experiments show, that a i386 with 1G RAM QEMU runs during tcc phase into oom-killer) <OriansJ>bauen1: well we do have a version of sha2 buildable by M2-Planet; although a few bugs crept in and I haven't had the time to fix them yet. Also I've started on a ungz for M2-Planet, so live-bootstrap could drop all of the big git submodules. <OriansJ>I really need to make mescc-tools-extras a proper thing so that all of the M2-Planet buildable pieces are together and organized. <janneke>OriansJ: while working to finish wip-full-source-bootstrap, i added ignoring of "extern" to m2-planet <OriansJ>janneke: thank you for the new functionality in M2-Planet <melg8>Hi, can somebody explain, why there are like a bunch of different versions of autoconf - and why they all build in such order? <stikonas>melg8: autotools are not 100% backwards compatible <stikonas>as for the order, this is somewhat related to autotools depending on themselves <stikonas>so current order is mostly what was easier <stikonas>it might be possible to reduce number of autotools a bit <stikonas>so initial versiion of autoconf 2.52 is "manually" bootstrapped using sed (sed replaces some placeholder variables that normally configure script does <stikonas>also autoconf 2.52 is the last version that does not need perl <stikonas>although, it's not really strictly required to start with 2.52 <stikonas>some newer versions of automake provide ./bootstrap script but I think it still needs reasonably new autoconf <stikonas>but we definitely need quite a few different versions <stikonas>sometimes different versions might be needed even for a single package <stikonas>subdirectories might need diferent autoconf compared to top level configure <stikonas>those two packages are rather unusual, usually it's just 1 ./configure script <melg8>Okay, i'm tried to check what are differences between files after two separate runs, and except alot of differences - related to dates, i think i found something shady going on) when automake-1.11.2 build, it's configure file is different between runs. And inside i see - that one of them were generated with <melg8>"Generated·by·GNU·Autoconf·2.68·for·GNU·Automake·1.11.2." and second run "Generated·by·GNU·Autoconf·2.65·for·GNU·Automake·1.11.2." - both runs are from start to finish without any changes from me, except i've added chroot things to run it in chroot mode. <stikonas>oh and starting order of 2.52 is a bit due to historical reasons <stikonas>initially we only managed to build perl without any modules (miniperl), so we were limitted to autoconf before it was ported to perl (2.52 is the last version written in bash) <stikonas>hmm, so I think automake 1.11.2 is the first one that uses ./bootstrap script <melg8>what for autoconf/automake is used? <stikonas[m]>Ideally we should remove pregenerated files before running bootstrap.sh <stikonas[m]>Well that first "Generated by 2.68" suggests that bootstrap script somehow failed... <melg8>i can share .md version of diff files of two rans - it's like 22k lines or can share html version. <stikonas[m]>Well, I'm not at home now, so can't really fix it today <melg8>i'm not in hurry of any kind - just thinking how to help you to find roots of problem, because - i for myself will do it much longer - not knowing all system <melg8>you mean inside of src_prepare for automake 1.11.2 - before call for bootstrap? <stikonas[m]>If all auto generated files are removed, it might solve both your issue and that linked one... <stikonas[m]>I though bootstrap.sh works reliably, but apparently not :( <melg8>I have more questions who needs autoconf/automake in the end? <stikonas[m]>We do build some early stuff with custom written makefiles <stikonas[m]>But it's tedious to write them and they are also not portable <melg8>and why you use 4.0.4 gcc version? <stikonas[m]>Well, it's newer than what guix builds 2.95.3, so that's good. Going even further was a bit problematic <stikonas[m]>Anyway, 4.7.4 is the limit with tcc anyway as that's the last version written in C <stikonas[m]>I think some newer gcc versions also need more dependencies <melg8>okay, so i could test it myself - by which version of autoconf - should automake 1.11.2 configured? <melg8>another question - if i restart build from directory - without any manual cleanups - sysa creates exact version of resulting A system? so it should not affect runs? <stikonas[m]>If I understand you correctly, that's what tmpfs achieves, new run is always in a clean dir <melg8>now i'm really confused... if line says Generated·by·GNU·Autoconf·2.68·for·GNU·Automake·1.11.2. ... but i dont see 2.68 autoconf installing - 2.65 and 2.69 are used, not 2.68? - at least by names of .sh files. <stikonas[m]>2.68 is what was used to generate configure in upstream tarball <stikonas[m]>It ships pregenerated configure script for ease of use <melg8>A couple of questions - who runs after.kaem.run file? and i see that this is already sh file and it have cd in it, who provides sh and cd? at what step? <stikonas[m]>cd is probably part if mescc-tools or maybe mescc-tools-extra <melg8>so is there anything in use except kernel - from the host system? <stikonas_>oh, actually cd is probably built-in into kaem ***stikonas_ is now known as stikonas
<bauen1>so i'm now testing a simple wrapper around `build` that sets up DESTDIR, which makes run.sh readable again <bauen1>next would be a upkg_simple_build2 that could try to do some chroot builds <bauen1>live-bootstrap currently only has tar after we build it somewhere in run.sh right ? <melg8>i think it builds in run2.sh - really close to the end <bauen1>that's a bit far for me, guess that will have to wait for tar from mes tools <bauen1>and i broke something for some version of automake in run2.sh ... <fossy>the run2.sh tar is just a new version 