IRC channel logs

2020-11-06.log

back to list of logs

<OriansJ>vagrantc: well thanks to the recent help I got from nimaje to get mescc-tools working on FreeBSD; we learned what changes would be needed to be done to MesCC to enable it's Linux binaries to also run on FreeBSD.
<OriansJ>as for MesCC having issues with cross-compiling; we will just have to address that later.
<OriansJ>But you should be able to always build Mes.c reproducibly from the M1-macro assembly version.
<OriansJ>As M1 with the same options will always produce the exact same output regardsless of host/ISA/Kernel/wordsize
<OriansJ>NO EXCEPTIONS.
<OriansJ>So just use Guile to run MesCC to build mes.c and then you should be always able to get the same binary out. even on Debian kFreeBSD
<OriansJ>and ./bin/get_machine ${GET_MACHINE_FLAGS} should only cause an issue if it was set -eux and not just set -ex; unless the outside environment has an implicit -u
<vagrantc>it seems non-deterministic
<vagrantc>OriansJ: yes, but there's no way to ensure the linux binary emulation is enabled on the debian build infrastructure
<vagrantc>ah, yes, i forgot to push the set -ex fix
<vagrantc>or rather, pull it into the applied patches
<vagrantc>anyways, another day for another upload :)
*vagrantc waves
<OriansJ>vagrantc: what seems non-deterministic?
<OriansJ>hello CoderForLife
<CoderForLife>Hello and GN OriansJ
***terpri_ is now known as terpri
<vagrantc>well, i appear to be playing whack-a-mole now with mescc-tools ... amd64 appears to be fixed, but i386 is still failing on debian's build machines (but works fine for me locally): https://buildd.debian.org/status/fetch.php?pkg=mescc-tools&arch=i386&ver=1.0.1-5&stamp=1604652429&raw=0
<vagrantc>i've pulled in several of the patches from upstream mescc-tools, but since i can't reproduce the test failure locally ... kind of hard to debug
<vagrantc>+ LANG=C sha256sum -c test/test2/proof.answer
<vagrantc>sha256sum: WARNING: 1 computed checksum did NOT match
<vagrantc>+ out=test/test2/proof: FAILED
<vagrantc>is the notable part of that build log
<rain1>what is the difference between the two files?
<rain1>test/test2/proof.answer and test/test2/proof
<vagrantc>no idea, as i have no access to the files
<vagrantc>i guess i could upload again and cat them
<rain1>ah i understand why this is so hard then
<vagrantc>the test should probably be more verbose on failure
<vagrantc>all tests probably should
<vagrantc>if i could reproduce the problem locally, i could test, but it works just fine for my local builds
<rain1>yeah it could print a diff if the checksums don't match, that's a nice idea
<vagrantc>i'll try a few different machines to see if i can reproduce elsewhere
<vagrantc>oh, it gets more interesting ... https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/mescc-tools.html
<vagrantc>there, the first build succeeded, the second build failed
<vagrantc>and the first build was running an amd64 kernel, the second build a i686-pae kernel ...
<vagrantc>hrm. but the buildd.debian.org also was running an amd64 kernel ...
<vagrantc>aha!
<vagrantc>i was running my i386 builds without the linux32 personality set
<vagrantc>i can make it fail locally now
<vagrantc> https://try.diffoscope.org/yukxtfcthhcd.html
<vagrantc>ok, i guess i just need to pick all the patches
<vagrantc>because it works fine then
<vagrantc>ok, tired of debugging exactly which patches succeed and which fail to cherry-pick the minimal set ... just going to upload with all the patches from upstream :)
<OriansJ>vagrantc: well it is usually easiest not to have to maintain software and let other people do the heavy lifting.
<OriansJ>I do however find it funny seeing diffoscope comparing an ELF binary and sha256sum file (literally name and checksum for the ELF binary)
<vagrantc> https://buildd.debian.org/status/package.php?p=mescc%2dtools looks ok again
<vagrantc>OriansJ: i tend to like to prefer figuring out what the minimal change is to fix something, but yes, at some point happy to have others fix everything :)
<OriansJ>vagrantc: well the minimal delta would be what changes are required to get mescc-tools to have the debian specific files; otherwise the changes should be done upstream.
<OriansJ>as mescc-tools takes distro specific bugs extremely seriously
<OriansJ>if it doesn't work identically on ALL DISTROS and all POSIX kernels, there are bugs that need to be addressed.
<vagrantc>the debian gnu/kfreebsd case will be ... interesting :)
<vagrantc>i've got a virtual machine running it now, but prioritized getting the package fixed in more conventional environments first :)
<OriansJ>vagrantc: the only thing that might not work on non-linux systems would be thecreated Linux binaries not running. Otherwise everything else should work perfectly
<vagrantc>does it only create linux binaries?
<vagrantc>e.g. does it potentially create native binaries?
<OriansJ>vagrantc: well if you notice the binaries reference elf_headers/elf32.hex2 as a source input; if you look at that file, you will see that it is a hand written ELF header.
<OriansJ>specifically a Linux ELF header
<OriansJ>if you look closer at the test binaries, you'll notice manually written Linux syscalls.
<OriansJ>So it can create binaries for any target Operating system. One just needs to manually deal with that target's specific details.
<OriansJ>EG it can be used to make Windows com and exe binaries without a single line of hex2 or M1 changing.
<OriansJ>if you look closely hex2 only understands reading hex; :labels, %pointers and &addresses in big and little endian format (with a hair of architecture specific pointer encoding logic)
<OriansJ>M1 only understands: DEFINEs, %numbers, "RAW Strings" and 'hex literals' and simply passes the :labels, %pointers and &address, along with its output for hex2 to deal with.
<OriansJ>There is absolutely nothing Operating system specific in any of it. Minus the bit in hex2 dealing with architecture specific pointer rules. Nothing is actually architecture specific either.
<OriansJ>So regardless of the host Operating system and architecture and implementation. Source code passed with specific options must always produce identical output. NO EXCEPTIONS.