<xentrac>for a compiler you also have to implement all the desired primitives; the difference is that you have to do it in your target language, such as assembly, instead of your implementation language <OriansJ>./bin/M3-Meteoroid-x86 -f tmp/min.o -p <OriansJ>M3-Meteoriod now is fully reading ELF files correctly and I just need to add the relocation work and then it'll be done (then I have to add the amd64, armv7l and aarch64 pieces) ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<OriansJ>Hagfish: thank you. although the real treat is I think I made it the most easy to understand of all linkers; with the added benefit it can link gnu assembler and NASM relocatable ELF files (With meaningful error messages and -p and -P for looking deeper into the files) <OriansJ>Then when I finish M3-Comet, we will have a drop in replacement for binutils in the bootstrap process and then janneke can stop producing M1 output and instead produce standard gnu assembly output (thus simplifying his porting process forever) <OriansJ>rain1: doing alright, how about yourself rain1 ? <rain1>hard to explain, but it is nice to see you <OriansJ>rain1: and it is always nice to see you as well <OriansJ>although part of me is apprehensive about the volume of the work I took on <OriansJ>nothing like being the person responsible for reimplementing binutils, guile and GCC in M2-Planet on one's plate to feel overly ambitious <OriansJ>but mostly it is just alot of unsexy, straight-forward, work. Which reminds me; I need to go back and get the kaem work back to the form fosslinux had created (I just couldn't juggle all the balls required when I did the mescc-tools-seed update) and revert 8296db068336040ee5887e3870635e5b3f6553ea so that fossy can get back to hacking on kaem (so that it'll be a bash replacement) <rain1>could there possibly be any way around reimplementing these tools? ***stikonas_ is now known as stikonas
<Hagfish>"thus simplifying his porting process forever" that's fantastic. you're not just helping one person with one current problem, you're helping humanity and its entire future <nimaje>why reimplementing the gnu variants of these tools instead of just what posix demands? <markjenkinsznc>I think because people are bootstrapping the GNU stuff which has become self-dependent on its own stuff not in posix <rain1>but why reimplement them at all if we already have the code <OriansJ>and we currently only have 1 from zero bootstrapped C compiler (M2-Planet) and the work to get MesCC running on Mes-m2 is non-trivial (with the irony that MesCC is unable to build the bootstrapped mes-m2) <xentrac>GNU stuff was starting to get dependent on GNU for building already 25 years ago