IRC channel logs
2025-08-17.log
back to list of logs
<matrix_bridge><Andrius Štikonas> perhaps a bit slow since we need to read .o file again but it seems to work <stikonas>I think just need to make combined stage0-posix release now... <stikonas>janneke: we'll need to get newly used defines into mes though... <janneke>stikonas: great, i just got a 0.27.1 ready that should support 1.12.0 :) <janneke>there's also a patch from you with 1.13.0 defines; but i haven't checked if that's enough to support 1.13 <stikonas>hmm, not sure if they are all there, let me check <stikonas>with latest defines that are already in mes <stikonas>then I'll check diff between that and M2libc <janneke>stikonas: /me just pushes staging and version-0.27 branches <stikonas>I guess I'll send a bit new patch on top of 0.27.1 <stikonas>and you can then ignore the patch that I already sent <janneke>i wanted to get 0.27.1 out soon because it doesn't build with gcc-14 and recent nyacc's <stikonas>you can always make a mini 0.27.2 that just adds support for new M2-Planet/stage0-posix <stikonas>janneke: by the way, while you are here, how much contact do you have with nyacc developers? <stikonas>ok, sent a mail to bootstrappable mailing list now about stage0-posix 1.9.0 <janneke>i usually mail to Matt Wette <matt.wette@gmail.com>, cc'ing guile-user@gnu.org <janneke>i'm wondering about the string-every and vector-fold bits <janneke>why not add them to mes, hmm and we already have vector-fold even <stikonas>well, as long as they can be done without psyntax.pp <stikonas>the idea of this patch was to rebuild nyacc pre-generated files with just mes <janneke>F_OK is on the wip-gcc4 branch (which has been waiting for far too long...) <janneke>and should be rebased some time soon <stikonas>oh nice, so this patch can be made a bit smaller then <ekaitz>janneke: what's gcc4 branch? building GCC directly instead of tcc? <janneke>ekaitz: nope, it's for building gcc4-core without glibc/musl <janneke>i've been bisecting musl function implementations but there is a whole cluster of dependent functions that cannot be bisected further <janneke>my guess would be the struct FILE* / filedes casting hack, but dunno <janneke>iwbn to rewrite that, ungetc and buffering come to mind, but that's quite a bit of work and no guarantee of success <ekaitz>the FILE* thing is practical but problematic <stikonas>ok, just tried to diff M2libc and mes M1 defines, this is what I got <stikonas>mosty additions except for -cmp +cmp_ebx,eax <stikonas>but I guess in mes we want to keep cmp too <stikonas>to keep compatibility with older M2-Planet <stikonas>hmm, actually mes-0.27 doesn't build with new M2-Planet <stikonas>include/signal.h:190:newline expected at end of macro directive <stikonas>but adding a newline between these 2 #endif works around it <janneke>stikonas: thanks, pushed some more stuff to wip <janneke>also, i found a nitpick problem with 0.27.1, so i can probably include these <janneke>but that will have to wait for a new round of testing <stikonas>janneke: you probably want to keep old cmp define too <stikonas>otherwise the older M2-Planet 1.12 won't build <stikonas>janneke: I've now identified which commit broke M2-Planet -> mes build (well, at least the current problem, there might be more...) <stikonas>it's the one that removes support for // CONSTANT <stikonas>anyway, let's hope that's the only problem... <stikonas>with that commit reverted, M2-Planet compiles mes sources into mes.M1 <stikonas>so I think it will be a respin of M2-Planet <stikonas>and then it will all work with M2-Planet 1.13.1 <stikonas>though I still recommend to add "DEFINE cmp 39C3" to x86 defines