IRC channel logs

<OriansJ>pder: mescc-tools-seed includes testing the checksusums of the resulting binaries if you do make clean test-x86 or make clean test-amd64 or make clean test-aarch64

<OriansJ>the checksums are in the *.answers files and the SHA256SUM files if you want to ensure each step during the bootstrap is perfect

<OriansJ>siraben: your ix.io link indicated that bin/pack_blobs is not a valid binary. So let us check the basics: is the checksum of the file 89b6bb845ae33fa30b5ee7edd2bdb543509237d2753c0270976428442ef4329a ? are the file permisssions -rwxr-x--- (0750) ?

<OriansJ>if all of those are correct: is your system reading the ELF header correctly? https://paste.debian.net/1178339/

<OriansJ>if the checksum is wrong, we can figure at what step it went sideways and hunt that down. if the permissions are wrong we can dig into why hex2 isn't setting the correct permissions by gdb and break FUNCTION_chmod and 488 = 750 in octal so the register should be correct

<OriansJ>If the host doesn't recognize the ELF header then the problem is with the host not the pieces in question.

<OriansJ>in fact every binary is 100% deterministic and should be identical regardless of host: https://paste.debian.net/1178340/

<siraben>just saw your pings (overnight for me), I'll look now

<siraben>pder: http://ix.io/2Jyw

<siraben>OriansJ: 89b6bb845ae33fa30b5ee7edd2bdb543509237d2753c0270976428442ef4329a bin/pack_blobs

<siraben>pder: oops sorry, I was checked out on the wrong mescc-tools-seed commit, here it is on latest; http://ix.io/2JyC

<siraben>so they all match exactly

<siraben>let's also make sure we're talking about building blynn-compiler from mescc-tools-seed, http://ix.io/2JyE

<siraben>M2-Planet segfaults

<OriansJ>siraben: now that would be a surprise. M2-Planet has been fuzzed to hell and back

<OriansJ>siraben: on blynn-compiler commit: 61d2178a9ed446453d3560271646722026768a83

<OriansJ>try M2-Planet --version

<OriansJ>see if it segfaults on that

<OriansJ>siraben: it is 20:44 here (8:44pm)

<siraben>M2-Planet --version

<siraben>Segmentation fault (core dumped)

<siraben>OriansJ: 8:50 am here

<pder>siraben: Those checksums match mine, and I always am testing with M2-Planet built from mescc-tools-seed. Do all binaries built by mescc-tools-seed segfault?

<siraben>weird, M2-Planet in bin/ works, maybe it is the ELF patch

<pder>I dont know anything about nix packaging works, but I would disable anything that tries to patch or strip those binaries

<pder>But I am confused because the checksums match mine

<siraben>I have 50ea82e70f30f135daf210210e7266e7ff8cad8a3bbc50b7883c8bf8750d5c4d for M2-Planet's checksum, correct?

<siraben>this is the checksum of the executable that actually executes

<siraben>Oh it differs, hm

<siraben>Ok so when M2-Planet builds I have b1f14ac56c57aa579b610de5c7d480fc5dbb4be9e185246ef77c07b937bf43cb as the hash, but when I perform `cp ./bin/* $out/bin` the hash changes

<pder>If I build commit b80accf40023bbf5f6f1d08da59256467bc6f1a0 of mescc-tools-seed, the sha256sum of bin/M2-Planet is b1f14ac56c57aa579b610de5c7d480fc5dbb4be9e185246ef77c07b937bf43cb

<siraben>Is it because the permissions changed?

<siraben>755 should be the permissions right?

<pder>cp shouldnt change the permissions

<pder>I tried copying M2-Planet to a different directory and got the same sha256sum

<siraben>Oh there's also a dontStrip option, I'll try setting that to true

<siraben>and it works.

<siraben>OriansJ: the two PRs I have open on blynn-compiler conflict, so when you merge one I can rebase the other

<V>siraben: it's probably an alignment thing

<V>Or at least that's the first thing I'd think of

<siraben>V: I see, I should try a binary diff

<V>siraben: nix run nixpkgs.vbindiff -c vbindiff [...]

<siraben>V: thanks

<OriansJ>siraben: the permissions should be exactly: https://paste.debian.net/1178362/

<siraben>OriansJ: yeah, permissions were not the issue, but the automatic stripping was

<OriansJ>siraben: well there was nothing to strip

<OriansJ>no paths or linker data at all

<OriansJ>as they are fully static binaries

<OriansJ>so you probably have a solid bug case for nix

<OriansJ>as nix strip should not be breaking statically built binaries

<fossy>agreed

<OriansJ>siraben: merged both;

<siraben>OriansJ: I think it's running regular strip

<siraben>I'll open an issue and see

<siraben>OriansJ: thanks.

<siraben>fossy, OriansJ: are you able to replicate the segfault if you run strip on M2-Planet?

<OriansJ>siraben: yes I can replicate the segfault after running strip

<siraben>That's strange because it didn't happen before with M2-Planet

<OriansJ>looking at the ELF headers it appears to try to only load half the binary

<OriansJ>it changes the File size to 13688 from 32056

<OriansJ>even though the segment is still exactly 32056bytes in size

<siraben>on the flip side of this bootstrapping project, how do I replicate building GCC 4.7 with MES?

<OriansJ>siraben: fossy did a nice bit on that: https://github.com/fosslinux/gcc-seed

<rain1> https://github.com/jjyr/jonesforth_riscv

<siraben>OriansJ: what's with the notice at the top of the readme? `NOTE: This fork of mescc-tools-seed is superseded by a new upcoming project.`

<siraben>tested the CI to see what would happen if precisely.hs fails to generate valid C code: https://github.com/siraben/compiler/runs/1611102652

<siraben>rain1: nice

<janneke>siraben: you probably know that the whole bootstrap from mes onward is used by guix

<siraben>janneke: yeah, it would be nice to replace Nix's bootstrap with that

<deesix>Why commit 5f0822619fad of mescc-tools-seed does (for phase 9)...

<deesix>- -f ../M2-Planet/functions/string.c \

<deesix>+ -f ../mescc-tools/functions/string.c \

<deesix>Also, that commit makes the AMD64 script to list two "Phase-8".

<deesix>!?

<rain1>:D

<deesix>Hmm, maybe to avoid the MAX_STRING change for the next submodule update. What a maze.

<deesix>... as M2-Planet d9504e3872e5 changes functions/string.c.

<deesix>mescc-tools-seed/makefile has test-x86 and test-amd64 using the wrong kaem-optional-seed (they use the one for the other arch since commit 402abf516404).

<deesix>Is ".PHONEY: clean" a typo there?

<fossy>OriansJ: siraben and the sucessor https://github.com/fosslinux/live-bootstrap

<fossy>I found it much too difficult to stop exposing the host environment to things like configure scripts in gcc serd

<fossy>So I restarted using an initramfs (making it reproducible as it is always in the same env)

<fossy>./rootfs.sh makes the initramfs and boots it in qemu

<fossy>you need a kernel seed named kernel in the root of the repo

<OriansJ>deesix: the reason for the change is M2-Planet purged half the string functions as they were not needed by M2-Planet to be bootstrapped. The AMD64 phase 8 was me forgetting to fix the numbering while I fixed everything else

<OriansJ>The reason for stripping out of the string function that used MAX_STRING as a constant is it caused a conflict with MAX_STRING as a global variable in M2-Planet.

<OriansJ>So I had to make the change to enable M2-Planet to support longer strings for the blynn-compiler bootstrap.

<plasma41>fossy: I see that rootfs.sh has a shebang of "#!/bin/bash". I don't see anything in that script that isn't implemented in a standard Bourne shell. Perhaps change the shebang to "#!/bin/sh"?

<OriansJ>deesix: I guess I have some problems in mescc-tools-seed to fix. and typos are kinda commen with me. so probably

<OriansJ>fossy: thank you for sharing the link. I honestly lost track (Way too much to do with the baby and all)

<deesix>At "Phase-5 Build M2-Planet from cc_x86" ./cc_x86 hold M2.M1 --> ERROR in create_struct Missing {

<OriansJ>deesix: on commit b80accf40023bbf5f6f1d08da59256467bc6f1a0 ???

<OriansJ>after you do git submodule update --checkout

<fossy>plasma41: um I think {a,b} is bash specific

<fossy>I can expand that tho

<OriansJ>also isn't the standard "#/usr/bin/env sh"

<OriansJ>as the default shell doesn't have to be in /bin/

<deesix>OriansJ, yes, that's the commit. 'git submodule status' shows the correct output for M2-Planet.

<nimaje>posix demands a /bin/sh

<nimaje>pretty sure it has to support {a,b}

<OriansJ>nimaje: dash does not

<OriansJ>deesix: when you cd in the folder x86 and do sha256sum -c SHA256SUMS what does it say?

<nimaje>yeah, freebsds sh also doesn't support {a,b} and I couldn't find it in the opengroup document, so I probably remembered wrong

<OriansJ>nimaje: mistakes are a natural thing. As we all should always be learning.

<deesix>OriansJ, OK for the outut of the completed phases.

<deesix>.*output

<deesix>hex1: OK catm: OK hex2-0: OK M0: OK cc_x86: OK

<OriansJ>and what is the checksum of the hold file? 74042774a39d59f45a2eba6a09c3baabada5c8e56249b3fd71848b90b1e7168e

<deesix>OriansJ, no... $ sha256sum x86/hold

<deesix>95efbfdb7e3d0c46a10e2b603950ae4b450947994ae1e23227b2a63abd965a31 x86/hold

<deesix>Hmm, I think the M2-Planet dir is not OK, even if 'git submodule status' says otherwise. Let me try something...

<deesix>OriansJ, solved. Sorry for the noise.

<deesix>The thing was that the submodule was in the right commit but its working dir was obsolete (my fault due to handling the submodules semi-manually).

<OriansJ>deesix: no problem, I rather have a dozen reports in mistake than 1 real issue missed

<OriansJ>thank you for alerting me and helping me trace it down to the cause

<deesix>Thank you.

<OriansJ>and thank you for spotting those errors in mescc-tools-seed that I need to fix

<OriansJ>and patches are up

<OriansJ>fossy: I guess you are looking forward to bauen1's kernel being able to fill that slot in your work.

<fossy>OriansJ: yes

<fossy>or another kernel

<fossy>I am trying to minimise kernel requirements

<OriansJ>as am I; it is amazing how few syscalls are needed to bootstrap all the way up to mes-m2 and blynn-compiler

IRC channel logs

2020-12-26.log