IRC channel logs
2022-08-14.log
back to list of logs
<stikonas>catm will force me to improve option parsing a bit <stikonas>before that option parsing was very simple and assumed that user will supply exactly 2 arguments... <oriansj>stikonas: depends, if UEFI provides an array, it should be able to stay the same; if it is a list it'll be a little more complicated and if it is crazy it'll be a lot more complicated. <aggi>the final fun musl-libc typedef unsigned wchar_t; tcc/stddef.h unsigned; gnu typdef int wchar_t <aggi>next, see configure tests do things, include conflicting headers, exclude headers... <aggi>besides, gcc and tcc digest such typdef conflicts different... didn't fully expand the variant matrix of this <aggi>again, it is particularly GNU and related builds... i'll try to remove this coreutils, tar and a dozen others which can be replaced with toybox or something else <aggi>sorry, had been digging for a while, again, because of, gnu <aggi>what's funny, about this, due to the wchar_t typdef mismatch, results in HAVE_C99_STDINT_H=0 by configure tests... <aggi>ok, GNU configure.ac may test for wchar_t variances, yet i fail to recognize the wisdom to break with sideffects against C99 integer types <aggi>yet, this seems what GNU thinks is appropriate to do <aggi>i'll remove this, hopefully won't need GNU tar nor coreutils nore any of this anymore <aggi>those GNU headers, not only do those cascade many #ifdef; not enough, those headers are generated from templates <aggi>it's not that i wanted to remove GNU, this must be removed <stikonas>oriansj: UEFI doesn't provide an array. We get a string of data. That's it. It's up to us how to use it but the way I was using it was to interpret spaces as argument separators <stikonas>(and also I kept it UTF-16 string for compatibility with UEFI shell) <stikonas> and that's also needed if we want to set arguments in UEFI boot manager (i.e. to bootstrapping without kaem-optional) <stikonas>so it's a bit lower level than POSIX arguments <stikonas>hmm, unfortunately I think I've made a bug in kaem-optional where string length is not set correctly... <stikonas>anyway, with this I can take the string of arguments, split it and push everything onto stack <stikonas>we'll probably needs something similar in M2libc... <stikonas>though this one does not set any argc... <oriansj>well we could store the ++options rather easily and then we would have both argc and argv set correctly <stikonas>I'll see if it makes sense to backport this to some of the earlier programs that are already done <stikonas>maybe hex2 can have this improved parser <stikonas>the other ones are pain to update for little benefit <oriansj>stikonas: well minimal is best for the early steps; M2libc can do much more advanced things as we can even do C code for it <stikonas>yes, hence I'm doing almost no error checking <stikonas>though I still free memory pools and close file handles (which we don't to in POSIX) <oriansj>well we do close file handles in M2libc but you are right about us not freeing of memory pools as of yet <oriansj>I guess I probably should give M2libc a proper malloc <aggi>so, system can be bootstrapped _without_ GNU gettext/intltool now, some cleanup and testing remaining <aggi>and i already tested replacing binutils with elfutils, two dozen of builds still block against binutils-ar <aggi>i'll try with tcc-ar next, which too was broken last time i tried <aggi>another test-run will be a tcc-only toolchain (CC,LD,AR,AS), to see how many builds require additional utilities from binutils <aggi>ideally, the entire _userspace_ of ~600 builds i got currently can be compiled/linked with a tcc-toolchain only (without gcc/binutils/elfutils) <aggi>btw. replacing libtool with slibtool(gentoo) passed with 100% of all builds, although gentoo tooling itself still requires libtoolize with their ebuild-system <aggi>with libtool i reject /bin/bash and bashism in general; can't test/re-implement various parts of the build-system without fully removing gentoo tooling <stikonas>though there seems to be some bug somewhere (maybe kaem) <stikonas>occasionally the whole process gets stuck