<doras>Yes, the workaround is broken. <doras>And it's broken because the help2man file is read-only. <stikonas>ok, so it is indeed the same thing I saw <stikonas>if I understand correctly it's the former <doras>Yes, adding "chmod +w" right before the workaround gets it working. <doras>The workaround is still needed for some reason. <doras>I mean, I don't understand what they were doing there. <doras>But if we have to do the workaround, I'll need the chmod. <doras>Thanks for the help, stikonas :) <stikonas>ok, I guess it can wait until your rootless PR... <stikonas>it's not immediately useful to live-bootstrap then <doras>I'll remove the double '/' while at it. <doras>I mean: #!//usr/bin/perl -> #!/usr/bin/perl <doras>sed: can't read */*/Makefile.in: No such file or directory <doras>Actually, I think Matrix took some of the above as formatted text. I'll try again. <doras>```"*/*/Makefile.in" is a very strange path.``` <doras>Hmmm, that works for escaping. <doras>```sed: can't read */*/Makefile.in: No such file or directory``` <doras>These sed tricks did work in the other versions of autoconf... I wonder what's different. <doras>Maybe I have a borked bootstrap directory at this point. I'll just start over rather than attempt to resume it. <bauen1>stikonas: so i thought about this some more, and the next step would probably be a better version of boot0, that is: a proper UART driver and a proper hex0, after that is probably a mix between the woz monitor and hex1 <bauen1>stikonas: and in some random order after that: sha2, dram setup, a microkernel (probably, as that allows adding additional drivers / components "easily") <stikonas>clemens3: by the way, my icedtea-8 build now succeeded <stikonas>bauen1: sha256sum would be non-trivial to write <stikonas>we have a C version, but assembly would be quite big <stikonas>and you actually don't even have assembly yet, just hex <stikonas>and everything before hex1 is also really painful to maintain/modifu <bauen1>stikonas: yes, it will be after hex2, and it might be quite a bit of assembly, but nothing complicated, you're just performing a bunch of A = B OP C operations in a loop, and have some constants <bauen1>it will be fun to write hex1 + uart0 driver again in hex0 :D <stikonas>well, yes, it will be simpler than writing M0 <stikonas>well, we do have a simple implementation <stikonas>and you can save some code by not doing match function <oriansj>stikonas: the reason why the channel doesn't allowing not identified posters here for a simple reason: a very bad rash of spam the last time we turned it off on Freenode. That being said for people just wanting to be lurkers, the IRC logs are public and can be searched. <oriansj>also note those with OPS permissions also tend to be busy and might take some time to respond to spam (myself, janneke, rekado and siraben) <oriansj>bauen1: in order to be considered hex0 it needs to support both # and ; line comments with all characters up until the lf (or cr in a few bios cases) being dropped; so having a restriction on the case of the letters in the line comments would be failing to implement the spec. <oriansj>that being said, it is ok to assume specialized hardware <oriansj>you can assume a VT52 connected to a serial port if it makes your work easier <oriansj>or 3 Heathkit H10 paper tape reader/punch attached (1 for loading the program, 1 for input and 1 for output) if it makes your work easier <oriansj>or even a custom bit of hardware responsible for loading something into memory <oriansj>just don't assume anything that requires turing complete and software to implement <bauen1>oriansj: is there any document describing the syntax of hex0 / hex1 / .... ? or just the stage0-posix implementations ? <stikonas>bauen1: but there are some arch-specific deviations, e.g. risc-v uses !~@$ for different purposes <doras>Strange. It seems /usr/bin/find ends up with a different checksum. <doras>I'll see if I can figure out why. <stikonas>doras: try running them through diffoscope <doras>Wow, it seems to have a ton of dependencies, at least on Fedora. <doras>Something seems very off here. <doras>No wait, I was looking at something else. <doras>Anyway, I think it would install all the possible comparator tools or something, and there are hundreds of them. <doras>sudo dnf install diffoscope --setopt=install_weak_deps=False <doras>stikonas: any tips on how to use it? <doras>It seems there are a ton of differences. <doras>But most of them are just different function offsets and similar. <doras>It's hard to point out a specific interesting change in all this offset noise. <bauen1>doras: diffoscope is an amazing tool, you can compare basically any files in the known universe, and there for it has quite a few dependencies that you usually don't need <stikonas>well, you can also try comparing object files <bauen1>doras: yeah, maybe don't paste it into irc but upload the file somewhere <stikonas>not sure if that's relevant but findutils is the first package that imports gnulib <stikonas>I guess it's right but for some reason binaries are really different <stikonas>well, I suggest trying to narrow it down by running diffoscope on individual .o files <doras>I'm rebuilding it without cleanup now. <stikonas>that might give you a clue on where things go different <stikonas>maybe some path got hardcoded and is different in buildstream build <stikonas>so that can introduce a lot of noise in the diff <bauen1>interesting, so if i'm reading this right there are a different number of symbols in both files, one having 2629 the other only 2610 <bauen1>doras: so link order is one of your problems i think <doras>What do you mean by link order? <stikonas>well, if object files are the same, that might also indicate link time issues <doras>Link of the individual .o files? <bauen1>in one find first there is getcwd.c then hash.c ; in the other it's hash.c then human.c <bauen1>doras: yes, the point where all the .o files are given to ld <bauen1>doras: and i'm guessing they're not sorted before that is done, or maybe they're sorted by time which is always bad <bauen1>search for '696:', that is the start of a very large change block, any previous changes are probably due to offset changes <bauen1>getcwd.c doesn't even seem to be linked in one of them lol <bauen1>if you look at the output of `strings` in the diff, getcwd.c is just missing from one of them <bauen1>yes, it's not linking getcwd.c in one of the find utilities you've compared <doras>I don't understand how every other executable and library up until that point was fine. <doras>Even all the other executable in findutils are fine. Only "find" isn't. <bauen1>doras: it obviously doesn't need the getcwd.c code <bauen1>doras: if you can't repeat the failure, then there's also a chance that it was caused by timing issues, or very unlikely but possible bit-flips :D <stikonas>getcwd function is actually used in find.c <doras>I haven't tried repeating it yet. <doras>stikonas: in which operation? <bauen1>stikonas: but is that actually exported by getcwd.c ? <bauen1>stikonas: it seems that only exports rpl_getcwd <doras>So are the changes coming mostly from gnulib from what you can tell? <doras>And they only appear in "find" because it statically links with it? <bauen1>/after/findutils-4.2.33/build/findutils-4.2.33/find/find.c:702 <bauen1>doras: stikonas: in one of the finds that line calls rpl_getcwd in another it calls getcwd <bauen1>so that is probably the cause of the difference but not the source of the problem <doras>Maybe one of my sources is borked. <stikonas>well gnulib checksum is 0cfbf866bc39c31f25fa0e56af1e56c5e5c92fc1e5d51242ebafef7ea211f3d5 gnulib-8e128e.tar.gz <doras>And this is what I see locally. <stikonas>and permissions on findutils/gnulib allow overwriting files for non-root users? <doras>I'll compare their entire build directory. <doras>And check for permission oddities. <doras>So this is suspicious. There are a bunch of Makefile files that have "REPLACE_GETCWD = 1" in them in one and "REPLACE_GETCWD = 0" in another. <doras>bauen1: how did you know to focus on getcwd? <stikonas>doras: well, that was the biggest difference in that diffoscope output <stikonas>so the difference might be coming from ./configure script finding something different <doras>I also see this: "#define HAVE_PARTLY_WORKING_GETCWD 1" <doras>Also this is different: "#define D_INO_IN_DIRENT 1" <doras>I think these are the two big differences, and they indeed come from a configure decision. Two of the tests are failing. <doras>These fail: "checking whether fchownat works with AT_SYMLINK_NOFOLLOW" <doras>And: "checking for d_ino member in directory struct" <doras>conftest.c:125: error: include file 'error.h' not found <doras>conftest.c:210: error: unknown type size <doras>Sorry, the second one happens in both cases. <doras>The second failure is due to fchownat failing to change ownership to a file called "conftest.dangle" <stikonas>hmm, fchownat does not work in buildstream ? <doras>I don't think it has any special limitations. <bauen1>doras: if you look at iirc the symbols, there is a very large block of changes that starts with 696: containing the name of a linked file <bauen1>doras: so everything after that is likely due to messed up offsets <doras>Actually some config checks are failing only in the non-BuildStream build. <doras>"checking whether getcwd handles long file names properly" works only for BuildStream <bauen1>oriansj: thanks for the feedback, i'll update my boot0 to indicate the language supported and then work on a proper hex0 implemented in hex0 (because ignoring comments etc... is done easily by a human in this case i'd say) <stikonas>doras: where as it's not mounted in chroot and qemu modes <doras>stikonas: but so does run.sh <doras>Oh, maybe only for sysb and sysc. <doras>Any reason it's mounted only for sysb and sysc? <doras>But we do during sysa's bootstrap, and we do mount device nodes. <doras>The "populate_device_nodes" function. <stikonas>mounting proc needs actual mount command <doras>stikonas: you think this is the reason for the "getcwd handles long file names properly" checks fails only for the non-BuildStream modes? <stikonas>well, try not mounting in /proc and see if that helps <doras>I'm not sure if I can with BuildStream. I can with the bwrap mode though. <stikonas>you also got wrong checksum in bwrap mode? <doras>I didn't. It mimics the chroot mode with the exception of setting device nodes up front. <doras>And therefore I only have /proc for sysc. <doras>Anyway, the lack of /proc is the lesser issue. The bigger issue is why the fchownat and the d_ino tests in fail during configure. <doras>I never bugged configure scripts, to be honest. Does it create all of those test scripts somewhere I can audit? <bauen1>doras: so the config.log should give you a clue as to where and how it failed, then take the line numbers you find and look what the actual configure script does, then cross reference that with the files that generate configure (iirc configure.ac) <doras>I did the first half, and I see two specific tests that fail. The tests are executables that it builds and tries to run. <doras>The question is how do I debug those executables. They do far more than a single thing, so any one of these could have failed. <doras>I'll try compiling them locally and see what happens. <doras>By locally I actually mean inside the bootstrap sysroot, but in a standalone manner. ***Noisytoot_ is now known as Noisytoot
<stikonas>yeah, these issues are somewhat annoying. Especially because things are reproducible in the same environment, so would be acceptable. But we have differences between different environments <doras>The test program from the second link above works for me when built manually. I created a symlink called "conftest.dangle" and built it using tcc. <doras>Renaming the symlink to something else confirmed the test program actually works because it then failed. <doras>So... what now? Why is configure's exact-same test program broken and mine isn't? <doras>Obviously it's a permission thing, like most of the other issues I encountered, so I need to check why the configure script is not handling files correctly. <doras>I'll try to look at it to see if I can find anything wrong about it. <doras>Actually, maybe it should be a dangling symlink, as the name suggests. I'll try it. <doras>Nope, the test program succeeds. <doras>And yeah, I pretty much did the exact same thing the configure script does, with the exception that I did it in some other directory because I have no idea where it creates its test programs. <doras>Maybe my tests are wrong. I'm assuming that I can reproduce BuildStream's sandbox using bwrap to enter the sysroot on-demand and perform actions, but maybe I can't. <doras>Because running ./configure this way also suceceds.