<oriansj>looks like live-bootstrap gets that file by running ./configure <oriansj>in the file: sysa/musl-1.1.24/musl-1.1.24.sh <oriansj>which seems to include case statements (which kaem doesn't support at all) <oriansj>but the makefile: sed -f $(srcdir)/tools/mkalltypes.sed $(srcdir)/arch/$(ARCH)/bits/alltypes.h.in $(srcdir)/include/alltypes.h.in > $@ <oriansj>which comes after you build make and sed; so that is fine <oriansj>so M2libc would need to get extended to support the building of bash, make and sed before M3 could be used to build with musl libc <stikonas>yes, that configure script is way too complicated for kaem <stikonas>and I might have fixed reproducibility issues in autogen, so now need to rerun live-bootstrap a few times to check... <stikonas>(mostly simple things, like adding configure flag, defining env variable or outright deleting file that is useless to us) ***lukedashjr is now known as luke-jr
***haxcpu is now known as ay
<oriansj>now to create a boatload of tests, figure out the correct answers, language lawyer the answers (and compare against gcc) then fix up M3-Preprocess to cover what is required. ***lukedashjr is now known as luke-jr
<oriansj>The C99 standard is about 500 pages, but only 19 of them are dedicated to describing how the C preprocessor should work and what it does specify is batshit crazy. <oriansj>I might have to stop trying to think of C preprocessing as a compilation and rather an interpreted language <oriansj>so #define and #include could have their meanings swapped. >.< ***lukedashjr is now known as luke-jr
<oriansj>what is even more odd, GCC doesn't throw errors when something violates the C spec. ***lukedashjr is now known as luke-jr
<muurkha>well, in most cases violations of the C spec can't be detected mechanically at compile time <muurkha>and GCC does in some cases intentionally extend it <oriansj>for example the C specification defineds endif-line as # endif new-line so in theory a line comment after the #endif but before the new-line should be an error and that is easy to detect at preprocessing time. <muurkha>-pedantic makes it complain a little more <oriansj>but not about these sorts of details <muurkha>hmm, interesting, I didn't know the comment removal was at a later stage than #endif processing <muurkha>when it is done would seem to affect whether #endif // FOO_BAR is an error or not <oriansj>comments can even be preserved in the preprocessed output <muurkha>the usual approach to comments is to treat them as whitespace in the grammar, but I have no idea if that's what C99 does or not <oriansj>muurkha: yep and the specification doesn't dictate that detail <muurkha>presumably whitespace is allowed between #endif and newline? <muurkha>or is "#endif \n" also supposed to be an error? <oriansj>well the grammar would indicate that wouldn't be valid <oriansj>but no C preprocessor I have seen thus far sticks to the actual grammar strictly <oriansj>if anything the rule seems to be do kinda like what GCC does; regardless of it is in the standard or not <oriansj>and what GCC does is largely a mash of old functionality that someone had a need for ***lukedashjr is now known as luke-jr
***lukedashjr is now known as luke-jr
<fossy>mihi, stikonas[m], yes, I did email Bruce Korb a long while ago - nearly a year ago! <fossy>was there something you were wondering? <fossy>bruce wasn't able to give much help, unfortunately <fossy>bruce korb is no longer active with autogen <fossy>oh, i see bootstrappable mailing list re: this <fossy>bruce is uninterested in bootstrapping it. but that doesnt preclude the current maintainers accepting it... <stikonas[m]>fossy: Still, the way gnu-autogen-bootstrap works is slightly hacky, so a bit hard to see how it can be integrated as is (I.e. patches do break a bit of functionality in bootstrap binary) <stikonas[m]>I would say in the current form it makes more sense as a separate project <stikonas[m]>fossy: anyway, I might have solved reproducibility issues in my PR, though I still need to rerun live-bootstrap to test it ***civodul` is now known as civodul
***lukedashjr is now known as luke-jr
***lukedashjr is now known as luke-jr
<stikonas>hmm, I'm taking back the words that I fixed autogen... Somehow my patch didn't work... <aggi>stupid question: is there any easy way, to replace GNU configure[.ac]/makefiles ? <aggi>tracked bdep/rdeps against autoconf/automake/libtool, and as expected it's all falling apart, the entire dependcy graph <aggi>ideally, there won't be any build remaining, which requires pre-generated configure/makefile with anything <aggi>one victim of this approach: ncurses, have to try netbsd curses (from sabotage linux project or oasis linux who integrated it) <aggi>however, there is many other components, which i would prefer to keep (nfs-utils, squashfs-utils whatever, it is many) <sam_>no, you can't really replace it, you'd be better off just pre-generating (you can make your own dist tarballs) <sam_>makefiles in particular are tricky, note that automake produces POSIX makefiles <sam_>so the issue is when people handwrite their own junk <aggi>hi sam_, the generated configure script and makefiles are not acceptable <aggi>and the bootstrapping status of GNU-buildsystem (including perl), isn't acceptable <stikonas>cause you need to figure out all those defines that configure figures out for you <aggi>and, i am not sure yet, how many builds <stikonas>in live-bootstrap we do this up to the point where autotools are available <stikonas>but those builds tend to be missing features, etc... <aggi>though, i do keep the elogs from gentoo <stikonas>(though enough to bootstrap further packages) <stikonas>one example of missing feature: sed in place editing was losing executable bit from scripts <stikonas>and that is because sed was compiled with -DHAVE_FCHOWN <stikonas>and each define you miss will either cause compile error or missing feature <aggi>ok. toybox userspace utilities are among the first builds, which covers alot, and doesn't require configure[.ac]. bingo. <aggi>ncurses -> replaced with sabotage linux netbsd-curses <sam_>stikonas: we're hitting a lot of hell like that wrt sed-style issues because of Clang 16 :) <stikonas>oh, configure messes up flags with clang 16? <sam_>(look at my first comment) <sam_>clang 16 makes some things errors by default which means configure tests often give bad results <sam_>the change is good by itself but the journey is terrible <sam_>the bugs on that tracker do not yet include such failures because they're harder to find <stikonas>that's often the case that change is good... <sam_>(we have to diff config.log & grep for new errors) <aggi>i got a devdrop here, tcc-toolchain fully replacing gcc/binutils (except libc with it asm) <aggi>300 builds in my overlay, a noteworthy amount related to, autoreconf troubles