<fossy>ok i've got past that hurdle <fossy>i'm still very unsure why it was happening <fossy>hooray, we have a semi-working mes-tcc!!! <oriansj>fossy: good, I look forward to seeing your work ^_^ <oriansj>janneke: I am importing your BOOTSTRAP notes into bootstrappable.org (please correct any errors that I made) <oriansj>Also by finishing slow-utils, we wil be able to pull mescc-tools entirely out of the scheme only bootstrap <oriansj>I'll aim to finish it tomorrow for you <oriansj>(as you only needed hex2, blood-elf and M1; of which hex2 and blood-elf are already done) <fossy>oriansj: i assume slow-utils is written in scheme <oriansj>The only part of it that mes-m2 doesn't already support is the modules bit <oriansj>and I probably could pull that out pretty easily too <fossy>i see, that enables the scheme bootstrap <oriansj>as I only used (use-modules (srfi srfi-9)) which is Needed to support record type <fossy>i assume slow-utils is irrelevant for a 357-byte bootstrap? <oriansj>fossy: it is for after mes-m2 is done <oriansj>basically: the current scheme map should be the mes-m2 part and above being done (but use guile instead of mes-m2) <oriansj>which reminds me: gio if you so choose to do so and say put a copy of https://github.com/oriansj/talk-notes with your gitlab (or other hosting location) with your asmc and nbs info added to it's bootstrappable.org; I would love a link ^_^ <oriansj>currently instead of slow-utils, it is mescc-tools <oriansj>which is just the C versions of the exact same functionality <oriansj>I know for absolute certain that the steps at and below mes-m2 are absolutely correct (the ones above usually change when janneke makes good progress in MesCC and only he can say for certain if they are absolutely correct or what I need to change to make it accurate again) <fossy>not having -C for mescc makes everything like 2x slower <fossy>then i tried to make it reproducible properly <fossy>and now when i build it the proper way without anything from /usr/local it segfaults <fossy>where would i start with debugging this segfalt <xentrac>are you familiar with debugging segfaults in general? <fossy>but even with -g it dosent want to give me debugging symbols :x <xentrac>you can run gdb without debugging symbols <xentrac>have you gotten it to segfault under GDB yet? (or, do you have a core file?) <fossy>xentrac: i'll go and do some research and come back with something. <fossy>because i don't have a clue how to do core files and the like <xentrac>I didn't know valgrind could give you a stack trace; that is useful <fossy>ok so i had somehow got my bin/mes in a very strange state that made segfaulting binaries <fossy>so i just went back to step 0 with mes-seed and build back up *fossy hopes i get a tinycc compile working now <janneke>fossy: "it worked before" is where i have been so many times, esp. with cross-builds <janneke>it's a big reason for me to only want to build such things in guix <oriansj>janneke: and a big reason why I made all stage0 pieces zero knowledge builds. (nothing about the host system or environment change the output in any way) <oriansj>I like to think of it as the lazy solution <oriansj>Less work to build, less work to cross-build and less things to cause me the developer issues <janneke>yes, i am not saying that i won't work on non-guix implementations, i just would not want to do my first/only implementation in an fluid environment ***ng0_ is now known as ng0
<xentrac>a different approach to verifying binaries <fossy>janneke: unfortunately the whole point of this project is trying to get it to always Just Work in a fluid environment with no external dependencies <fossy>well its difficult to make sure it works everywhere, with no external dependencies <fossy>just when I've got it working on my machine <fossy>I try it somewherre else and find just that one external dependency that crawled in <fossy>and then often its a lot of debugging to fix <janneke>fossy: i don't think the whole point of bootstrappable is to make it work everywhere <janneke>i think the whole point is to eliminate the trusted computing base <janneke>it would be nice if most people would be able to reproduce it, and use it <janneke>and it would be nice if it would not break down when you change a tiny thing <janneke>but running a bootstrap in a "dirty" or uncontrolled environment is a bad idea when you want to have the guarantee that you are considering all dependencies when building a software <janneke>but that's just my idea, bootstrappable can be something else to everyone <fossy>janneke: well that is a reasonable point <fossy>eventually my idea would be for this to run in an initramfs <fossy>and that would elimate the "has to work everywhere" issue and also elimates the finding of external dependencies problem <fossy>maybe i might backtrack and make this initramfs /first/ and then continue development with the initramfs <janneke>yes, well i'm just saying that adding noise is going to cause pain, esp. when doing something like cross building, which is similar to what we are doing <janneke>until we have built glibc, there are the mes c library include headers, there is the mes c library <janneke>it is very probable that somewhere in the build systems of the packages that lead up to building those, you find hardcoded /usr/include of something <janneke>that may work, but it may give unexpected results <dddddd>wow! ugly commits in the talks repo. Bots commiting? What can go wrong? (;