<stikonas>fossy: so I tried to build guile but I'm running out of ideas... <stikonas>well, it actually builds but doesn't work <fossy>stikonas: can u provide an error or whatever? <fossy>Is it a straight up segfault <fossy>the issue is pretty clear, null pointer in data in frame 2 <fossy>wtf is up with filename=0xb5b40 "\025", as well <fossy>I need to read the code, brb <oriansj>stikonas: probably want to share a pointer to the build process (the git commit on a experiment branch perhaps), so that those less familiar with live-bootstrap can get to the same point you are, such that they can help too. <oriansj>a sort of git checkout this and do that to get this binary with this checksum provides a quick sanity check for anyone else wanting to help. <stikonas>although, I don't have any build process for guile yet, I was just running some testing with ./configure and make without even autoreconf or other stuff <stikonas>so something goes bad there between guile and boehm-gc... <stikonas>so after that I just get guile-3.0.7.tar.xz, unpack it <stikonas>./configure --prefix=/image --libdir=/image/lib/musl --build=i386-unknown-linux-gnu --disable-shared --target=i386-unknown-linux-gnu --host=i386-unknown-linux-gnu --disable-jit <stikonas>make[3]: *** [Makefile:4555: guile-procedures.texi] Error 1 <stikonas>which is just after guile binary was built and is first attempted use <Hagfish>have you narrowed down what parts of the build environment are necessary for the issue to occur? <Hagfish>i'm assuming the issue doesn't occur with a distro-provided toolchain <stikonas>although, those patches are removed from guile3... <stikonas>it was unrelated to that link but that link helped me find the right solution <stikonas>boehm-gc had to be compiled with CFLAGS='-D_GNU_SOURCE -DNO_GETCONTEXT -DSEARCH_FOR_DATA_START -DUSE_MMAP -DHAVE_DL_ITERATE_PHDR' <stikonas>ok, guile has just been built... Tomorrow I guess I'll try it with pp-syntax bootstrap <stikonas>(by the way, one minor issue I noticed with pkg-config is that it fails to build later with gcc 4.7.4. But that's fine, we shouldn't need to rebuild it anytime soon) ***dekenevs is now known as kitzman
<stikonas>hmm, after reimporting gnulib (to recreate auto-generated files) guile seems to require gperf (and hence C++ compiler). I'll see if we can somehow get rid of this dependency... <stikonas>I think Melg8[m] had similar problem with coreutils <oriansj>well all dirty secrets come out when you fully bootstrap code. But gperf seems the sort of thing we probably could remove as a dependency (for atleast the bootstrap guile) <stikonas>oriansj: yeah, it looks we only use meh_iconv function from gnulib's iconv module. I just created a stub that returns the same data. A bit of a hack but it seems to work <stikonas>maybe some minor things dealing with encodings would be broken, but we can always do a rebuild of guile after g++ and gperf <stikonas>hmm, somehow in live-bootstrap mihi's pp-syntax-bootstrap does not regenerated identical pp-syntax.pp.scm file. But I think it is close enough to work, maybe gperf patch broke something <stikonas>anyway, I think I've got guile working now, just need to do a couple of rebuilds to get hashes and check reproducibility <NieDzejkob>gperf sounds like something that could influence the sort order for guile's hashtables <stikonas>anyway, as long as psyntax-pp works I think I'm happy, it doesn't have to by identical <stikonas>but I think functionally it will be identical <oriansj>stikonas: well the really interesting bit is if we get a blob of difference between the proper bootstrap and the prebuilts. <stikonas>oriansj: well, differences are in that pastebin above... <oriansj>NieDzejkob: in theory a proper hash table just does a hash and insert order (or insertion sort if one needed it to be properly ordered for reasons) <stikonas>it's not just hash table, I basically removed iconv support and replaced with stub... <stikonas>(and btw, outside live-bootstrap psyntax.pp was identical) <stikonas>I should push my experimental branch, otherwise it's not clear what I meant <oriansj>well if one does a replace in the file with: t-e838bff-dd8 -> t-680b775fb37a463-dd8 and t-e838bff-dd9 -> t-680b775fb37a463-dd9 then they should be identical files (no idea why the why the whitespace might be different) <oriansj>well iconv only changes between character sets and everything should be straight ascii (as indicatable by sin) <Hagfish>another great commit, thanks stikonas! <Hagfish> patch <../../../guile-psyntax-bootstrapping-guile-3.0.7/stage2.patch <Hagfish>it's not obvious from that context that that relative path takes us to a file which is covered by a checksum <stikonas>well, it does on unpatched guile outside live-bootstrap on my system <Hagfish>it would probably make more sense to me if i had studied how these steps fit together, but it just keeps me a small sense of breaking encapsulation, if code is running in one directory and applying patches from a very different one <Hagfish>i guess you "cd module/ice-9" right before it, which explains two of the ".." <Hagfish>yeah, i probably makes sense in context, actually <stikonas>directory where patches are doesn't really matter.... <stikonas>although, something is wrong with rootfs.py tarball downloader <stikonas>it somehow fails to download gc-8.0.4.tar.bz <stikonas>yes, and I can reproduce with minimal python3 downloader <stikonas>I get 4.5 MB tar instead of 1.1 MB tar.gz <stikonas>hmm, I think it's probably requests library autounpackign it <stikonas>argh, it's the feature of requests library to unpack automatically... <oriansj>shell out to a variable string (set to wget for now) so that it'll avoid unpacking and enables an instant future replacement with ipfs (or gnunet, etc) <stikonas>strangely it only happens with this one file <stikonas>maybe something to do with HTTP headers on the file server <stikonas>ok, I think I fixed live-bootstrap's python code... <mihi>stikonas: ftr, when rebuilding psyntax-pp on 32-bit Debian (with the official regen script, not with my bootstrap) I also get changed (shorter) identifier names. The result works fine too. I ignored it as it does not happen on 64-bit. But if you are curious, it may provide some clue why it happens. <stikonas>thanks for explaining. I'll update my comment, that's useful info to know <stikonas>argh, that's a bit annoying. GNU autogen searches for guile 1.8 or guile 2.0 but not for 3.0 <vagrantc>how recent is autogen? guile 3.0 is fairly new <stikonas>vagrantc: but guile 3.0 is the only guile that has pp-syntax bootstrapped <stikonas>oh, there is slightly newer version from 2018, but probably still too old