| 16 Oct 2025 |
 Alyssa Ross | BTW: if something is going to be broken on every musl distro (like this fix), please try to take the fix upstream before working around it in Nixpkgs. If we all do this (and the other distros usually do), it's less work for all of us than if we all have to separately apply the same workarounds downstream. | 17:02:29 |
 matthewcroughan | I can't find a reference to off64_t in their sources on github | 17:02:31 |
| Alyssa Ross | hmm, maybe it got fixed already? | 17:02:42 |
| matthewcroughan | The reason I make the PRs isn't always to get it merged, but to provide a reproducer that allows others to tell me that it should be upstreamed | 17:03:06 |
| Alyssa Ross | presumably the build error shows you were off64_t was used | 17:03:08 |
| matthewcroughan | I'm not as experienced, so I need someone like you to tell me that I need to upstream it | 17:03:14 |
| 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 |
