<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>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>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 :) <OriansJ>vagrantc: what seems non-deterministic? ***terpri_ is now known as terpri
<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 <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>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>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>i was running my i386 builds without the linux32 personality set <vagrantc>ok, i guess i just need to pick all the patches <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>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>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>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.