| 16 Oct 2025 |
matthewcroughan | More like a request for comment really | 17:03:39 |
Alyssa Ross | ah, in that case drafting the PR is a good way to communicate that | 17:03:49 |
matthewcroughan | Okay I can start doing that | 17:03:56 |
Alyssa Ross | otherwise there's a risk that somebody merges it without understanding your intention that it not necessarily be merged as is | 17:04:19 |
Alyssa Ross | thanks for all your efforts btw :) | 17:04:32 |
matthewcroughan | headpat accepted | 17:04:47 |
matthewcroughan | Alyssa Ross: Actually it does look like it's the perl core that's broken? | 17:09:44 |
matthewcroughan | > /nix/store/xi08qryndrv2a2vih9s4n5kzfp8hzn9r-perl-5.40.0/lib/perl5/5.40.0/aarch64-linux-thread-multi/CORE/proto.h:10777:15: error: unknown type name 'off64_t'; did you mean 'off_t'? | 17:09:45 |
matthewcroughan | that's not coming from DBI, it's coming from perl core, no? | 17:09:52 |
matthewcroughan | lib/perl5/5.40.0/aarch64-linux-thread-multi/CORE/proto.h | 17:10:06 |
Alyssa Ross | oh, interesting | 17:12:00 |
Alyssa Ross | looks like it | 17:12:01 |
Alyssa Ross | I'm surprised that hasn't been fixed already if it's in perl | 17:12:11 |
matthewcroughan | Yeah, I'll just note it down in the PR anyway for posterity | 17:12:30 |
matthewcroughan | Alyssa Ross: I run into other issues like this in Python, that seem to me to be 32 vs 64 bit issues, do you agree?
g++ -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall -fPIC -I/nix/store/wskvcibvzlm1rp3j244m4dlmzxnjzsn9-python3-3.13.8/include/python3.13 -c _re2.cc -o build/temp.linux-aarch64-cpython-313/_re2.o -std=c++17
_re2.cc:252:1: error: cannot convert ‘std::nullptr_t’ to ‘Py_ssize_t’ {aka ‘long int’} in initialization
252 | };
| ^
_re2.cc:296:1: error: cannot convert ‘std::nullptr_t’ to ‘Py_ssize_t’ {aka ‘long int’} in initialization
296 | };
| ^
_re2.cc:340:1: error: cannot convert ‘std::nullptr_t’ to ‘Py_ssize_t’ {aka ‘long int’} in initialization
340 | };
| ^
| 17:27:00 |
matthewcroughan | I saw this kind of thing a lot when compiling old fortran code | 17:27:07 |
matthewcroughan | This only happens on native musl | 17:27:16 |
matthewcroughan | native musl being 64 bit only | 17:27:22 |
matthewcroughan | * native musl being 64 bit only, hence the need for off_t instead of off64_t, 64 is the only option | 17:27:41 |
matthewcroughan | * native musl being 64 bit only, hence the need for off_t instead of off64_t, 64 is the only option, so you don't have function names for 32 and 64 | 17:27:55 |
Alyssa Ross | that's not quite how it works — off64_t was a temporary hack 20 years ago so you could do partial codebase conversions. Nowadays you should be setting _FILE_OFFSET_BITS=64 so off_t is always 64 bits. | 17:28:58 |
dramforever | no, this is a c++ problem | 17:29:28 |
dramforever | musl's NULL is
#if __cplusplus >= 201103L
#define NULL nullptr
#elif defined(__cplusplus)
#define NULL 0L
#else
#define NULL ((void*)0)
#endif
| 17:30:05 |
matthewcroughan | but musl hasn't been updated, so what changed to make this drv fail | 17:30:26 |
matthewcroughan | it formerly built | 17:30:36 |
matthewcroughan | perhaps it was the default python version that changed? | 17:30:52 |
Alyssa Ross | only way to know for sure is to bisect | 17:31:27 |
dramforever | i actually don't know what package this is | 17:31:42 |
Alyssa Ross | (or take shortcuts to the same end result looking at commit logs) | 17:31:42 |
dramforever | nevermind it's fb-re2 | 17:32:04 |