<fossy>pder: yeah im trying to figure that out <stikonas>fossy: so I've got autoconf 2.52 working (PR a bit later, maybe tomorrow) <stikonas>although, autoconf might need some further bootstrapping if we need newer versions <stikonas>annoyingly autoconf 2.53 depends on 2.53 <stikonas>later they depend on the previous version <OriansJ>and I am pleased to announce M2libc now properly flushes file buffers without needing to call fflush prior to exit or returning from main but also does the correct thing for _exit and skips closing of file buffers as per the C standard. <stikonas>oh, that's good. Some softare in the bootstrap chaing does not properly flush <OriansJ>just need to make sure every last bit of the libc tweaks are flawless <OriansJ>and of courese I get armv7l and AArch64 wrong but everything else right <stikonas>pder: have you mentioned you had some trouble building binutils with tcc-mes? <stikonas>here it seems to work if I just run shipped configure <stikonas>although, I had less luck with autoconf (probably need some specific version) <pder>the issue I was having was actually with tcc-musl. Getting this error: /after/include/musl/bits/alltypes.h:323: error: too many basic types <stikonas>CC="tcc-mes -D __GLIBC_MINOR__=6" AR="tcc-mes -ar" RANLIB=true ./configure --prefix=/after --target=i386-unknown-linux-gnu --host=i386-unknown-linux-gnu --target=i386-unknown-linux-gnu - <stikonas>-disable-shared --disable-nls --disable-werror <stikonas>and there are also a few bison scripts we need to rebuild? (or at least touch) <stikonas>pder: well, if tcc-mes works I guess we can use it... <stikonas>it's possible that, we might need multiple autoconf versions on the same package (top level vs subdir configure scripts) <OriansJ>and the fixed version for AArch64 and armv7l is now up and M2-Planet has integrated it already <OriansJ>The process of replacing file_print with fputs is slow but it'll finally make M2-Planet a much more standard C program and Compiler <OriansJ>and I'll be adding a char* int2str(int x, int base, int signed_p) to bootstrappable.h to give a lisp style number->string sort of function to C <OriansJ>because atoi isn't standard and it expects you to pass it the buffer. <OriansJ>and making it univerally behave (only excepting 32bit numbers and actually handling the -2147483648 case correctly unlike ntoab) <OriansJ>hopefully I'll be able to pull all of the bootstrap.h functions out of mescc-tools and M2-Planet and provide only the absolute core of value. <OriansJ>supporting base-2 through base-36 and being correct for all inputs <OriansJ>and if calloc fails return NULL so that the calling function can catch it and deal with the mess but not have to deal with allocation details. <OriansJ>and with the recent fflush behavior change We have achieved a healthy speed increase as well. <OriansJ>it can now write a 25MB file in 3 seconds flat (iterating over int2str a shitload) <OriansJ>up next in M2libc is string.h and other new fun libraries <pder>OriansJ: that all sounds great. One thing I noted when debugging blynn-compiler and doing lots of printing numbers is that it would malloc new memory each call, so eventually I would run out of memory. It would be nice to be able to pass in your own buffer <fossy><stikonas> annoyingly autoconf 2.53 depends on 2.53 <siraben>pder: oh? I thought blynn-compiler used its own large array to manage memory? <fossy>stikonas[m]: wheres that configure from? <pder>siraben: when I was debugging blynn-compiler, I was often printing out debug info to compare the M2-Planet build with the gcc build. The call to numerate_number allocates memory each time that is never freed and I was doing this millions of times. <Hagfish>i'm glad there are people out there who still stand up for proper software engineering principles <siraben>heh having a discussion on that right now in a different channel <siraben>I don't think it's really a concern. Because lockfiles serve the purpose of pinning dependencies down exactly whereas nominal (and therefore inexact) specifications are more lax about what dependencies are used <siraben>In general you can't even be sure a minor version bump of a dependency wouldn't break your package, I've had that problem happen to me before and lockfiles were useful to revert. <Hagfish>i've seen a library deliberately introduce a breaking change into a minor version on the basis that they were making the behaviour match the documentation <Hagfish>(following the documentation up until that point would have resulted in broken code, so no one was using it how the documentation said) <Hagfish>Hyrum wasn't expecting malicious developers :) <siraben>that behavior gives off such chaotic neutral vibes <Hagfish>it takes a special type of sociopath to use the excuse "well you should have been following the documentation" when following the documentation would have resulted in your code not working <siraben>the article does raise the point that because of lockfiles, it can take years before you have all dependencies (direct or transitive) of a Go/Rust program "secure" <siraben>I guess an overriding mechanism would be nice <Hagfish>i think that it must be a false dichotomy to choose between "lock to a specific tested version" and "allow some wiggle room for security updates (which lazy/malicious developers then drive a bus through)" <siraben>For certain languages (Python/Haskell), Nixpkgs actually maintains a package set of it, but for others (Go/Rust) you just specify the hash of the lockfile and are done with it <siraben>in the former case overriding to any degree is supported, but not in the latter case <siraben>Hagfish: what would you have instead? <siraben>pretty shocking that minor version bumps can/will be used for breaking changes <Hagfish>i think it requires a different way to look at the problem <siraben>lockfiles are like an extreme solution to this <Hagfish>probably what i'm proposing is that the issue of solving version dependencies is pushed to a third party who does the integration work for you, i.e. your distro <pabs3>modified bundled deps of random commits is more worse :) <Hagfish>but i know that there are scalability problems with that *pabs3 notes that most of the HN thread thinks the Gentoo post is ultra-stupid <siraben>Yeah. I've packaged C, Rust, Go, Python packages for Nixpkgs before and I have to say, C and especially Python probably take the most effort to do successfully. <pabs3>(it is huge yet vastly underestimates the amount of embedding) <siraben>I've seen embedded copies but as submodules <pabs3>(I can post them to the list if wanted) <stikonas>fossy: oh actually, numbers in README.md and run.sh will again be out of sync... <OriansJ>pder: I believe there is a more standard C function for that; that I'll probably include in strings.h for M2libc and if not, I'll create one just for you. <OriansJ>Hagfish: we always knew that incompatible forks and lazy developers were the default. The Cathedral and the Bazaar showed rather clearly that developers don't care about security just only the features that they want. Software only ever bloats. <OriansJ>The fact that there are known security vulnerabilties because of developers not caring shouldn't be a surprise to anyone here. <OriansJ>Bootstrapping is a security issue of the most essential kind; which has been ignored and forgotten for nearly a hundred years before we came together to actually address it correctly. <OriansJ>ironically they didn't call out Java which is so bad that (and I quote): The only working solution with the current Java developement community is to forget the idea of shared libraries and simply having the JARs package all the libraries they depend upon and only shipping Java runtime/interpreter/compiler. <OriansJ>Although reading the HN thread, I can't help but feel the argument is really about programmers needing someone who cares about compatibility and stable ABIs ***stikonas_ is now known as stikonas
<pder>stikonas: the tcc "too many basic types" error can be triggered simply by creating a trivial C program that includes "typedef int int" <pder>so something is causing that code to be generated in the preprocessor <pder>no, i was simply trying to run configure with the same arguments and env vars as guix <stikonas>when I tried musl I've got somet erorr about alloca redefined <stikonas>by the way, yesterday I've got autoconf 2.52 working, but not sure how useful it will be for us (might be enough for binutils 2.14, but a lot of other software needs at least 2.54 which needs newer perl... <stikonas>anyway, I think I'll not push autoconf to master yet until we have a proper user for it <pder>interesting, so I almost had complete success with a tcc-musl build of binutils. I had to adjust a few things in config.h in libiberty related to typedefs for pid_t and uintptr_t <stikonas>well, if you manage to build it, you can then try touching .y files to rebuild them and see if it's still builds... <stikonas>(and even later we need to rebuild Makefile.in's) <stikonas>fossy: by the way, where did you find that sha256 is 16x less likely to produce collisions? That's seems wrong <stikonas>I would thing sha256 is significantly less likely to collide <fossy>stikonas: actually you are correct <fossy>I wrote that pretty late, idk what I was thinking <stikonas>hmm, so for sha256 I guess you need about 2^128 hashes to observe collision with reasonable chance <stikonas>so my very rough estimate would be 2^120 <stikonas>since different versions are not always compatible... So it's not clear if we should start with 2.52 <stikonas>and 2.52 is quite old, a lot of software that we want needs newer <stikonas>unfortunately that also requires newer perl <fossy>are we ready to attempt a gnu toolchain in that case <fossy>stikonas: also can we yet use Perl for Perl configure <stikonas>and only autoconf 1.4 or older worked for me on current perl <stikonas>fossy: so my current problem with perl 5.6 is <stikonas>tcc -DPRIVLIB_EXP=\"/after/lib/perl5/5.6.2\" -c -o perly.o perly.c <stikonas>perly.tab.c:1662: error: incompatible types for redefinition of 'yydestruct' <stikonas>hmm, this one is probably something wrong with defines, should be fixable <Hagfish>stikonas: huh, intriguing errors, but that's way outside my area of expertise. have you tried dangling this sort of puzzle in front people in a perl channel (or a bison channel?)? <fossy>stikonas: is bison new enough? <stikonas>ok, the other perl define errors sorted out, only bison left <pder>I was able to get binutils-2.14 to build and link properly with tcc-musl. It required a few hacks to force it to use alloca.c. <pder>this was with running the configure script <stikonas>keep in mind that you need to run autoconf in a few subfolders too <stikonas>hmm, actually many first try touching .y files <stikonas>and I think I might be close enough to perl 5.6.2 <stikonas>I think removing one line from bison-generated perly.c file helps <pder>I tried touching all the *.y files and reran make <pder>it built but had some warnings in the ld directory <stikonas>oh, actually removing that line from .y file works <stikonas>and path to perl 5.18 should now be clear <stikonas>hmm, if perl 5.6.2 is functional though... <stikonas>it can't rebuild itself... Can rebuild one file in 5.18 but crashes on the other file <stikonas>pder: so maybe now you can try autoconf? <stikonas>I would suggest trying one by one (there are maybe 10 configure scripts or so) <pder>Yes, I will pull in your changes and try it <stikonas>I'm not sure, but some configure scripts might require different autoconfs... <stikonas>anyway, I'll try to sort perl 5.6 first, it should be close... <pder>So in this old version of LFS they used binutils-2.14, autoconf 2.57, automake 1.7.6, and perl 5.8.0 <stikonas>I saw some page telling which autoconf/automake is used for gcc <stikonas>pder: anywya, that LFS page tells me I need to get newer perl first... <stikonas>these versions of autoconf and automake won't run on 5.5 <stikonas>pder: oh, but I don't think that LFS page uses autoconf 2.57 and automake to actually rebuild binutils' configure file <stikonas>so we might have to experiment a bit to find what works