<stikonas>fossy: so any idea what to do with guile? Try to get glibc first? <stikonas>hmm, maybe some distro has some musl patches for guile ***nckx is now known as jorts
<OriansJ`>bootstrapping: an adventure where you have to know other people's shit <stikonas>nothing similar to what I'm observing with configure <stikonas>oh, maybe we need to install autoconf-archive <stikonas>hmm, it could be that gforce_de1977's bash build has different hashes due to gcc defines that are automatically defined <stikonas>gforce_de1977: worth checking output of gcc -dM -E -xc /dev/null <stikonas>and then check if bash uses anything that is different <fossy>stikonas: does guile use autogen <stikonas>fossy: by the way, CI failed with some strange failure <fossy>we will see if it happens agagin <stikonas>fossy: in any case we have a away to deal with autogen <fossy>but we will def need it for later gcc probably <stikonas>I don't want to hammer main gnu server on each CI run... <fossy>i remember when it was introduced <stikonas>I guess we should be able to build the version just before that... <stikonas>but buildign python might need building openssl <fossy>eh, we will have to do it at some point <fossy>openssl shouldn't be hard at all <fossy>i have doubts that such a new glibc will work but we can try <stikonas>hmm, most of the stuff actually builds now that we have gcc <stikonas>way fewer problems and workarounds needed than with tcc <stikonas>although, I'm a bit unsure at what should we aim for in the short term <stikonas>there are maybe things that will eventually be useful <fossy>this is how i envisinge what we should do: <stikonas>yeah, that's my though for medium term... <stikonas>but the question is what do we need to do to get to autogen <stikonas>guile needs libunistring (another gnulib package) <stikonas>it might buidl with musl, but we need to solve configure problem <fossy>how about we solve gnulib first <fossy>because theres findutils and pending tar and libunistring <stikonas>well, gnulib according to my reading should be quite compatible <stikonas>so everything appart from findutils might work with just latest checkout <stikonas>findutils wouldn't have latest autoconf thoug <fossy>if there are no releases, there could be api breaks all over the place that are never detected <stikonas>Note: From time to time, changes are made in Gnulib that are not backward compatible. When updating to a more recent Gnulib, you should consult Gnulib’s NEWS file to check whether the incompatible changes affect your project. <stikonas>well, gnulib issue is quite annoying, but at least we know we don't need to bootstrap anything so solve it <stikonas>hmm, I wonder how git checkouts build ... <stikonas>there must be some mechanism in build system... ***jorts is now known as nckx
<stikonas>fossy: so git checkouts seem to have bootstrap script that runs gnulib-tool automatically <stikonas>maybe we can delay findutils until after gcc then? <stikonas>as far as I remember, we only use it a bit in autotools/libtool ./bootstrap scripts <gforce_de1977>stikonas: but why should my bash build output different results, it's always on the same cpu/kernel/whatever... <stikonas>oh, even on your system it's not reproducible <stikonas>then maybe some timestamp is slipping in <fossy>gforce_de1977: can you upload two binaries to somewhere + i will compare? <pabs3>siraben, fossy: so my mail didn't reach the list, I guess I need to subscribe and resend <OriansJ`>oh and for extra fun the M1 and hex2 used by mescc will also be faster <OriansJ`>got all the way up to kaem working with M2libc; just need to figure out the kaem segfault reason <OriansJ`>I'll try to sort this out when I have time. <OriansJ`>how the heck is GCC setting token->value to "" when token is calloc'd and value is never assigned??? <gforce_d11977>fossy: regarding different bash5.1 / bash-binaries: there are some links already in the backlog, let me search: <gforce_d11977>my goal for tonight is having base64 and let the bootstrap run e.g. 20 times so i can see in the log (via base64) the binaries <stikonas>bauen1: do you know if it would be possible to hide some of the stow complexity in some bash function? <stikonas>most of the command line arguments are the same <bauen1>i already have a test implementation of a "upkg" utility that does the stow + a bit of house keeping <bauen1>so you can only have a single version of a package "selected" at a time <bauen1>but i've realised i need to extend it to support multiple operations in a single go <stikonas>yeah, I think you'll have to experiment a bit to find what works nicely <stikonas>I'm not having a second attempt at GNU Tar 1.34 <bauen1>the only drawback the current way of storing "packages" has it that you need seperate invokations per package <bauen1>or write a bit of perl to invoke Stow.pm from the same perl process if you want to do so with a single invokation (to rotate libraries etc) <bauen1>but it's simple and easy to understand, can be extended with a /upkgs/pkg/current symlink to the "installed" version to make for a simple "package manager" (upkg) <stikonas>I had more luck with directy using gnulib-tool than ./bootsrap script from tar repo <stikonas>(we are still a bit low on tools and bootstrap script assumes that we have those) <fossy>stikonas: 1. i would prefer /not/ to use a submodule wherever possible, as this requires more processing on the host system (bad). 2. (not a problem but out of interest) how did you generate the list in import-gnulib.sh? <stikonas>hmm, we can think about something else instead of submodule <stikonas>although, it will work... (submodule is just way of distributing it) <stikonas>but we'll need ot use something on the host anyway <stikonas>and I think we'll need a lot of different revisions... <stikonas>each package depends on different checkout of gnulib... <stikonas>although, I'm not convinced that there is less processing... It's just that instead of processing on the host, remote git server does processing <stikonas>but if you think snapshot is better, I can switch to snapshots... <fossy>i think the main advantage of tars is that they are easier to "check" their validity <stikonas>but then checksum is checked from inside bootstrap <stikonas>then we don't need to download million of gnulib snapshots