|
06:51
[Coke] left
07:34
ShimmerFairy left
07:55
ShimmerFairy joined
08:45
[Coke] joined
|
|||
| patrickb | Quick status update: I have any-break support (i.e. break on all possible break positions) working in the debug server. Next: hunt an occasional dead lock or seg fault in moar I observe about 1 in 4 times during startup of a debug session. | 09:06 | |
| tellable6 | 2026-03-28T21:26:47Z #raku-dev <[Coke]> patrickb 2026.03 is ready for binary releases. | ||
| librasteve_ | rakudoweekly.blog/2026/03/31/2026-...lease-191/ | 11:37 | |
| grayeul | timo: (and others) - I've modified your container file for building moarvm/nqp and changed it to be more like the rpm build I'm trying to work out. One of the main diffs is relying on installed rpms for the 3rdparth dependencies. Maybe there are some version differences there that are having an impact. | 15:42 | |
| In any case, with this file: gist.github.com/grayeul/b9e6d1fe45...67ee7df9cb which tries to build 2026.03 -- even on Rocky9 I'm getting the error I mentioned the other day. `/usr/bin/ld: ./libmoar.so: undefined reference to `mp_expt_n'` | 15:43 | ||
| So, I'm also using 'mock' to build the rpm from a src.rpm. And when I do that for moarvm.2026.02 it works (at least without error) but when I try using the above container for 2026.02, I get an error that it can't find /usr/bin/moar when it tries to run a chmod. It didn't seem to complain about building or copying moar to /usr/bin -- and I don't see that error with mock, so not sure what is up with that. | 15:46 | ||
| ah -- I now see in the 2026.03 changelog, that libtommath requirement is 1.3.0 -- and Rocky9 only has 1.2.0 and 2026.03 says it requires mimalloc 2.2.7, which is not available (via std repos) for Rocky9 *or* Rocky10 | 15:59 | ||
| Update: gist.github.com/grayeul/d0d395e2a8...55ec22c7f1 shows a container build that appears to succeed for moarvm, but fails for nqp on Rocky9 (timo: this is what you asked for yesterday) | 16:23 | ||
| [Coke] | ah, you're not building 3rdparty/ but are using system versions? we could also have modifications in our versions (but not sure if we do) | 16:38 | |
| grayeul | right -- but trying to determine if/where that is a specific problem.... | 16:59 | |
| I could potentially build static versions... and include whatever 3rdparty stuff is in your submodules... seemed 'cleaner' (but not necessarily easier) to use system-provided versions. But that *will* make it harder to update when dependencies change. | 17:01 | ||