<oriansj>Hagfish: technically, I'm open to *ALL* bootstrapping paths. <oriansj>If you want to make a haskell compiler in assembly and use it to build a scheme interpreter to run a C compiler; I am here to encourage you to do so. (Hint blynn-compiler can be built by M2-Planet) <oriansj>If you want to bootstrap upon the ether blockchain spending your own cash on boatloads of gas: go for it <oriansj>If using the microprocessor you found in a sex machine is what you want as your basis of trust and added that architecture as a bootstrap chain of trust to check all the others: cool look forward to seeing that. <oriansj>If you want to build a computer out of individual transistors: awesome, can I have the schematics? <stikonas>mid-kid: you can't run autoconf scripts using meslibc <stikonas>you can at best run configure scripts that were already prepared using autoconf <oriansj>unmatched-paren: and if a conflict arises inside our community, I'll be here reminding everyone that we don't have to agree on how to do anything and forking is actively encouraged. The easier it is to fork the better <stikonas>I don't think forking happens that often <stikonas>like it was said here, wayland is not a fork, it was written by xorg developers, they just didn't want to use X12 name <oriansj>Only by empowering others can we truly empower ourselves <oriansj>stikonas: forks happen all the time, the key is to just merge them often to make the deltas easier for resolving of merge conflicts <mihi>stikonas, thanks. I know I cannot regenerate the autoconf scripts (config{ure,.*}) without autoconf, but I thought running should work. Now I found out that sed panics while building the Makefile, only that meslibc's panic does not print a useful error message, nor make the build fail. So tomorrow I will try to patch sed to at least tell me the errno inside the panic "couldn't flush..." line. <stikonas>well, I meant real forks (e.g. libreoffice vs openoffice or ffmpeg vs libav), not standard development. <oriansj>stikonas: I feel those are a reflection of the success of a community. Enough people exist to enable two different visions of solving the same problem at the same time. <oriansj>much like there being hundreds (if not thousands) of desktop enviroments that failed, those that found success made our world a better place <oriansj>for some i3 is best, others kde is best, others gnome3 is best, others mate is best.... <oriansj>the forking, creating a competitor and all the rest are good <stikonas>it makes calling autoreconf a bit more explicit but I think it's better to be more precise <stikonas>I'm trying baremetal bootstrapping next, so probably no other live-bootstrap requests in the near future <stikonas>hmm, stage0-uefi kaem would either need to get UTF-16 input or we need to write a function to convert chars to wide chars... <stikonas>former is a bit inconsistent with the rest of sources and stage0-posix but latter would add extra bytes to the kaem-optional-seed binary <stikonas>hmm, I guess it's not super complicated, just insert a zero byte every read <stikonas>hmm, if we are doing that it's probably not too much work to also keep uefi shell compatibility <oriansj>stikonas: I'd just say 2 conversion functions should be simple enough <oriansj>or really just one to strip out the null bytes on the read <oriansj>or we might not even need to do that at all as hex0,hex1 and hex2 should be ignoring null bytes entirely <oriansj>actually none of the programs until M2-Planet actually look at the char** argv so in theory no changes would be needed as they are just passed straight to the syscalls <fossy>stikonas[m]: cool, i will look at it in an hour or so <fossy>i'm slowly getting python together, (outside live-bootstrap for now) - just to see what the path is <fossy>this UEFI stuff sounds really good, gets us closer to metal <stikonas[m]>oriansj: reads just read what is in the file but we need to add zeroes before passing to syscalls <stikonas[m]>Well, at C level, I think I can do it with uint8_t and uint16_t arrays <mihi>janneke, stikonas: I was able to pin down my meslibc issue: When compiling sed-4.0.9 against meslibc, and running "sed s/x/y/ /dev/null", instead of outputting nothing, sed fails to fflush /dev/null and the code in gcc's makefile does not continue with the rest of the command which would write the rest of the gcc Makefile. Guix probably got around this by using sed from gash-utils at that stage. <mihi>Not sure which place this is easiest to patch (meslibc, sed, configure script) ***ChanServ sets mode: -o janneke
<stikonas>well, it's a bug in meslibc that other components trigger, so ideally it should be fixed in meslibc <mihi>stikonas, yes, ideally. But it seems to me that meslibc uses the file descriptors directly as file pointers, and therefore cannot even detect whether the stream was opened for reading or writing. <stikonas>mihi: hmm, can't it implement something like M2libc? <stikonas>it seems that in this case M2libc is more robust <mihi>in M2libc, FILE is a struct, and in meslibc, FILE is a raw file descriptor. So yes, with structs it would be easy :) <stikonas>well, I'm just asking can't we port meslibc to struct file descriptor? <stikonas>there is a simple example (m2libc) how to do it, so can't be that hard... <mihi>I don't think it is hard either, it is just changing a lot of functions, so no quick&dirty bugfix. <mihi>OTOH, M2libc's "buffer everything on opening file" behaviour will probably get us into other issues, e.g. with coreutil's "head" command. But we could use a struct and still use less aggressive buffering like e.g. musl does. <stikonas>anyway, it depends on how much you want to use meslibc <stikonas>I've got an impression that you want to use it quite a bit <mihi>in fact, gcc/glibc are the last two things I want to build with it. <mihi>I would even go a glibc+tcc route, which some people claim they have done, but I was unable to (after patching out the checks for real gcc in configure script) <stikonas>you might need to rebuild gcc a few times... <mihi>yeah, I know, gcc rebuilds itself I believe 6 times in total, if you do the usual gcc->glibc->gcc without --disable-bootstrap. <stikonas>I remember in live-bootstrap we had to rebuild tcc with musl twice before it was not buggy... I.e. tcc-meslibc->musl->tcc-musl->musl2->tcc-musl2 <mihi>gcc-2.95 builds fast (compared to recent ones) anyway. <mihi>When starting this, I was assuming that at the point when I first build gcc, my build stack is 100% the same as guix uses. But I underestimated the impact of gash-utils, so I already needed to patch coreutils expr and dirname to work with meslibc. <stikonas>well, it also depends on compile flags... <stikonas>mihi: so what are you bootstrapping assumptions and goals? <mihi>I've heard of cases where gcc -O0 built with gcc -O0 caused the build to fail, but not sure whether they have been fixed <stikonas>you are trying not to use gash, and gash utils? <mihi>no guile, no gash, no gash-utils, and in general all source packages stripped down to reduce the number of "exotic" source that needs to be reviewed.