IRC channel logs
2023-07-14.log
back to list of logs
<stikonas>looks like mescc emits movslq_ instead of movzlq_ (a bit later than the previous problem) <stikonas>perhaps related to the comment in compile.scm ((wrap-as (as info 'long-signed-r)) ; huh, why not long-r?) <stikonas>so I think that fixes those 32-bit o functions in tcc, so a bit less patching is needed <stikonas>(still we have other asserts/segfaults when building meslibc with tcc) <fossy>pder: i was actually just running a build disabling ssp to test the same thing! thanks, i'll apply the patch shortly <fossy>stikonas[m], doras: i'm quite happy with the implementation in #309 :) <fossy>01:31 <doras> stikonas: never mind, I figured it out. I was playing with the `SOURCE_DATE_EPOCH` example, which is already exported globally using `export`. So if you "redefine" an exported variable with a `local` variable inside a function, it does not remove it from the exported list and any command executed from the scope of the function (or nested functions) would inherit this "local" <fossy>^ i guess this isn't unexpected behaviour, but that doesn't mean i like it :P <fossy>declare -x sounds alright to me <fossy>doras: i tested concurrency *pretty* thoroughly and i run almost every live-bootstrap with --jobs 6, so i hope that there should be few problems <fossy>doras: regarding Py2.5, do let me know if you run into that again, it looks a lot like a transient dependency issue i've seen pop up a few times in pythons <fossy>pder: I've been looking rather extensively into pregenerated files in nyacc <fossy>the situation is really quite problematic. locally i have nyacc mach.d being rebuilt using mes straight from the tarball, but the very very large problem is that nyacc's regenerator for mach.d files uses psyntax.pp, which we remove in live-bootstrap because it is a pregenerated file <fossy>which is where i am very stuck <fossy>(it was rather easy to have mach.d rebuild.. i just followed the same pattern for mes-use-module used for the rest of nyacc) <pder>fossy: that is tricky. Is it at all possible to avoid using psyntax? <pder>If I grep the nyacc 1.00.2 code I see no reference to the string psyntax <fossy>im guessing that the define-syntaxs might be able to be rewritten somehow else, but that is farrr beyond my scheme knowledge <doras>fossy: thanks. I'll update if the python build failure happens again. <doras>Well, this is GitHub, so PR* :) <doras>pder, fossy, stikonas: I see... definitely less segmentation faults with SSP disabled. It seems that `conftest` is still crashing when building glibc, though. Interestingly, I noticed that `conftest` is also crashing in live-bootstrap's own `gcc-13.1.0` bootstrap. It also crashes in `util-linux-2.19.1`, but I think this one isn't new. I'm not sure if these crashes are problematic, but here's the output from coredumpctl: <doras>Presumably "checking for assembler and linker STT_GNU_IFUNC support...". <doras>When built with live-bootstrap's gcc-13.1.0 with SSP disabled, that is. <stikonas[m]>Maybe something similar to what mihi did to bootstrap psyntax on guile could work on mes-m2... <oriansj>stikonas[m]: porting that to mes.c might be a serious test of the interpreter <doras>stikonas: would you say that live-bootstrap supports passing the number of cores to utilize for the bootstrap using the JOBS environment variable, or only through bootstrap.cfg? <doras>At least for the bwrap/chroot bootstrap modes. <doras>I'm not sure if environment variables are even passed to child processes at the early stage0-posix stages. <doras>The issue I have with JOBS being configured in in bootstrap.cfg is that unlike other parameters, it does not (or rather should not, by design) affect the build products of live-bootstrap. <stikonas[m]>We don't support environment variables until full kaem <doras>BuildStream has a concept of a "cache key", which is effectively a hash that takes all build inputs into account and gives the expected build product a unique ID. Same inputs (sources, system, architecture, environment variables, etc.) -> same outputs. This concept is important to be able to share build artifacts through cache servers. For example, if the official project CI (that is authorized to push build artifacts to cache server) <doras>already built live-bootstrap in the exact configuration as I'm trying to build it locally, a cache servers allows me to download the live-bootstrap artifacts in a matter of a few minutes instead of having to build it myself for hours. This concept is important at scale, when building hundreds of unique components. <doras>The only exception BuildStream offers is the ability to avoid inserting specific environment variables into the cache key, which was essentially made with JOBS-like environment variables in mind. <stikonas[m]>Well, unfortunately JOBS env variable has no way of propagating to child processes in stage0-posix <doras>stikonas: I'm currently setting it to 1, but this means building live-bootstrap takes around 4x-5x times more than what the CI hardware is capable of (12 cores). <doras>I would very much like to set it dynamically based on the number of cores in the current system, and to tell BuildStream to avoid this environment variable. <doras>Though I understand that this is problematic. <doras>Using 12 means my system would choke when building locally (I only have 4 cores), and I don't want to compromise on a magic number. <doras>I'll try to see if there's anything I can do on the BuildStream side to handle this better. <stikonas>fossy, oriansj: perhaps it's simpler to rewrite that nyacc generator in C? <stikonas>or does it need a lot of features that we get from scheme? <mihi>fossy, do you know if these 1 syntax-case and 5 syntax-rules is all that is needed, or rather only the tip of the iceberg? <mihi>and btw I am not sure whether mes might even have a syntax-rules implementation without psyntax, so it would only be 1 syntax-case (or when looking closer, only two clauses of it)... <mihi>none of these should be hard to rewrite as define-macro (just tedious), and when trying to bootstrap psyntax.pp, you would definitely need to rewrite more syntax-cases from psyntax.ss to define-macro. (Assuming they are not exactly the same that Guile also uses, in which case you could copy them from my work) <mihi>of course, if you think mes will be used for more things in live-bootstrap later, "investing" in bootstrapping its psyntax implementation is probably another factor that may offset what the raw number of lines to port suggest.