<stikonas>math.a contains 230 .o files, that's just under the limit... <stikonas>(I'm trying to see how messy workaround would be) <stikonas>pder: by the way, I was trying with MES_DEBUG=1, it can see all args up to arg[1259]: obj/src/unistd/writev.o <pder>interesting, where and when do you set MES_DEBUG=1? <stikonas>so everything is fine in lib/posix/execvp.c <stikonas>pder: I'll go to sleep now, but I guess one interesting test is to try to replace __sys_call3 with musl version __syscall3 from musl/arch/i386/syscall_arch.h <pder>Yeah, I was seeing what I could learn with strace as well <stikonas>musl version might not compile with mescc but we can patch mes libc once we have tcc <pder>If I run strace -v /after/bin/echo 1 2 3 ... 257, I can verify that the execve syscall is seeing all 257 arguments. However if I print argc at the start of main, the value is 2 <pder>possibly a bug in the mes crt? <Hagfish>not bootstrapping-specific, but it's great to have a site which explains clearly that transparency logs can mitigate these attacks <fossy>what if we compiled musl using tcc with like 5 .as <fossy>then compiled musl again with one ma <pder>fossu, i think the issue wirh having to shorten command lines can be fixed in crt1.c argc ia vasically getting truncated to an 8 bit value <pder>I think the movzbl instruction is wrong <fossy>pder: hmmm, that sounds about right <siraben>OriansJ: opened a PR to convert mescc-tools-seed's README into markdown <stikonas[m]>fossy: I tried splitting into 20 or so .a files and something failed... I probably did something incorrectly. <stikonas>but maybe it would be easier to look at that movzbl instruction now <fossy>stikonas: whats the complete command/s <stikonas>fossy: one moment, I'll give you scripts <stikonas>so I produced a lot of .a files with fix_linking.sh <stikonas>(i.e. tcc linked against mes libc but producing binaries for musl) <stikonas>oh, and I ran make install from musl to install headers and .o files too <stikonas>it would probably be nicer to get ./configure working for tcc but at least for testing I just copy pasted from keam files ***bauen1_ is now known as bauen1
<pder>fossy, stikonas: I pushed a branch named mes-crt-fix for review. Now commands can exceed 256 arguments. I added another patch to the mes-libc-patched stage and then rebuilt tcc after that <stikonas>especially since last nights workaround didn't work <stikonas>(although, I had another workaround in my mind) <pder>The build of musl libc.a is now 1716740 bytes. Does that sound right? <stikonas>pder: well, I think when you make PR, do it without musl commit <pder>It ended up being a nice test though <stikonas>and then I think we should recompile tcc with musl... but that's going a bit into the future <stikonas>pder: oh it's in lib/linux/x86-mes-gcc/crt1.c ? <stikonas>but maybe I don't understand mes libc well enough... <pder>if you git grep crt1.c it should be clearer <stikonas>I guess eventually we want to upstream both mes patches? <pder>janneke merged my qsort patch to master, but wip-m2 is not based on it <stikonas>well, we can keep patching wip-m2 for now <stikonas>pder: so later this evening I think I'll pull in your change into my branch then <stikonas>I can probably finish musl before fossy wakes up <stikonas>I have a couple of files if you want to play with musl in the meantime <pder>the crt patch should go upstream as long as its ok, and it should be applied to other archs as well <stikonas>I wonder how much we should rebuild with musl later... <stikonas>our binaries would probably be less buggy if we recompile <stikonas>e.g. I saw that tcc-0.9.27 is self hosting with musl but not with mes libc <stikonas>well, maybe for now I'll just rebuild tcc... Although bash might be an interesting case too <stikonas>with musl it should be possible to build libreadline <pder>that would be great to have an interactive shell <stikonas>well, we need to rebuild some coreutils too <pder>Not necessary for bootstrapping, but an editor would be a nice convenience <stikonas>but yeah, I get, you want interactive editor too <pder>ive been using busybox vi <stikonas>anyway, things are looking much better than a week ago... <stikonas>when I couldn't build new flex and bison... <stikonas>luckily bash builds with heirloom yacc... <stikonas>musl is much easier to build when you have bash <stikonas>pder: maybe we can even go tcc -> gcc 4 directly? <stikonas>I think guix went to gcc 2.95 because mes libc was only good enough to build that <pder>Thats a possiblity, I guess we will know when we try it <stikonas>pder: hmm, something is still going wrong... <pder>You are trying to rebuild tcc with musl? <stikonas>so I'm first building tcc-0.26 crosscompiler <stikonas>i.e. tcc linked that itself links to mes libc but produces binaries linked against musl <stikonas>hmm, must be something minor, because only a few symbols are missing <stikonas>well, I have to rebuild tcc to see if musl works :) <stikonas>those missing symbols are in libc.a though <fossy>try it maybe, if it does work we can usr it for now and later on maybe backport pacthes? <stikonas>I can build some simple things using musl but more complicated end up with a small number of linking problems <bauen1>i would love if tcc upstream could actually make a proper release <stikonas>maybe should switch back to /usr, that seemed to work yesterday <rain1>i think uppstream is kind of abandoned <pder>if you are static linking I wonder if you could be running into a problem with the order you link <bauen1>i mean mob sees plenty of development, just nobody wants to fix a release <bauen1>fossy: i'm sure package maintainers would also like a release <fossy>today: figuring out tinycc word size alignment <bauen1>and tbh i don't really love the way everyone can just push to mob, makes the history a bit of a mess <fossy>also very easy to indtroduce malicious code <bauen1>but i'm also a heavy user of `git rebase` so treat my opinion with a grain of salt lmao <bauen1>thinking of it, my most used git commands are probably `git status`, `git log`, `git add`, `git rebase`, `a very obscene one liner that force pushes every commit to gitlab one at a time` <bauen1>the last being because i want CI to run and succeed on every single commit that ever touches master <fossy>well that makes history a mess lol <bauen1>fossy: not to master, just to staging / development branches <bauen1>CI just ensures everything compiles and meets the absolute minimum requirements <bauen1>so if i ever need git-bisect it will actually work <fossy>I think for live bootstrap I will make master "protected" <bauen1>now my commit messages are still severly lacking so yeah <bauen1>fossy: it should be by default on github <fossy>I reguarly push to master in other projects which I def didnt make it protected on.. <bauen1>fossy: oh i meant by protected that force pushes are disallowed <bauen1>you can also set it to only allow prs then <stikonas>it might be that "tcc -ar" still does something different... <stikonas>so tcc -ar is still not working properly... <fossy>stikonas: I bet those four are meant to be in a seperate rile <fossy>I mean tinycc expects them to be in libc but they are in another file instead maybe... <fossy>which file when compiling musl has those symbols? <fossy>are they anywhere near each other in the linking cmd <stikonas>no, I don't think they are anywhere near <stikonas>maybe we'll have to build binutil's ar... <pder>did you try experimenting with the order in which you link? <fossy>oh or are you using their makefile <fossy>werwnt you using their configure <stikonas>hmm, I wonder if I can try to add those .o files to tcc at compile time... <stikonas>well, I can link them into another .a file... <stikonas>/after/musl-1.1.24/build/musl-1.1.24/obj/src/mman/mprotect.o /after/musl-1.1.24/build/musl-1.1.24/obj/src/signal/sigaction.o /after/musl-1.1.2 <stikonas>4/build/musl-1.1.24/obj/src/stdio/__stdio_exit.o <fossy>if you feel like dedicating effort to that up to you <stikonas>but I think we have to get musl to proceed... <fossy>I dont think it significantly improves readability to fix the underlying issue <fossy>And will probably take much more time <stikonas>well, but I at least want to see if there is any obvious cause why they are missing... <fossy>so im happy with hacky_lib workaround <stikonas>well, we only need to keep hack until we get ar <stikonas>the annoying thing about hacky_lib is that almost any package will need it... <stikonas>I wonder if we can patch musl to replace them with strong symbols? <fossy>stikonas: hm, are there ant other weak symbols <fossy>I bet this is my issue with linux kernel where I have to add .os to the final link <stikonas>fossy: other weak symbols might not be used in this particular case (compiling tcc) <stikonas>compiling flex 2.6.4 only hit 1 symbol, not 4 <stikonas>if I disable weak alias in typedef and convert into strong some symbols are repeated... <stikonas>fossy: yeah, so my testing with toy app confirms that all weak symbols are broken <stikonas>so hacky lib approach is not very scalable... <stikonas>ranlib fixes it but again, we don't have that either <stikonas>or maybe tha'ts just an artifact or ar s fixing tcc -ar archive by unpacking and repacking it