| 18 Oct 2025 |
matthewcroughan | https://www.openwall.com/lists/musl/2025/09/13/1 | 14:05:32 |
dramforever | no because this is inside unix_close_range | 14:05:37 |
dramforever | #if defined(__linux__) || defined(__FreeBSD__)
static int unix_close_range(unsigned int first, unsigned int last, int flags)
{
# if !HAVE_CLOSE_RANGE
return syscall(SYS_close_range, first, last, (unsigned int) flags);
# else
return close_range(first, last, flags);
# endif
}
#endif
| 14:06:05 |
matthewcroughan | ah yes, so it's like, musl doesn't have it | 14:06:25 |
dramforever | implementing unix_close_range in terms of unix_close_range would be funny ... no it wouldn't work | 14:06:25 |
matthewcroughan | so it tries to use SYS_close_range | 14:06:29 |
dramforever | what musl version are you on again | 14:09:08 |
matthewcroughan | 1.25, everything I'm doing is based on staging-next always | 14:09:48 |
matthewcroughan | if I'm ever behind it's by a day or two | 14:09:55 |
matthewcroughan | * 1.2.5, everything I'm doing is based on staging-next always | 14:10:11 |
matthewcroughan | this is gnu-musl-llvm and musl-llvm though, I went back to musl native for testing, and I get a different error there in nix-expr | 14:10:55 |
matthewcroughan | the error about close_range is from llvm/musl, so I guess it's about tha | 14:11:09 |
matthewcroughan | * the error about close_range is from llvm/musl, so I guess it's about that | 14:11:11 |
matthewcroughan | On native musl I get this from nix-expr
[35/35] Linking target libnixexpr.so
FAILED: [code=1] libnixexpr.so
g++ -o libnixexpr.so libnixexpr.so.p/meson-generated_.._parser-tab.cc.o libnixexpr.so.p/meson-generated_.._lexer-tab.cc.o libnixexpr.so.p/attr-path.cc.o libnixexpr.so.p/attr-set.cc.o libn>
/nix/store/24dkhnp0rpb1hvzx1h5frsbfjmgjfpk9-fortify-headers-1.1alpine3/include/stdio.h: In function ‘__to_xstring.constprop’:
/nix/store/24dkhnp0rpb1hvzx1h5frsbfjmgjfpk9-fortify-headers-1.1alpine3/include/stdio.h:80:28: error: inlining failed in call to ‘always_inline’ ‘vsnprintf’: function body can be overwritte>
80 | _FORTIFY_FN(vsnprintf) int vsnprintf(char * _FORTIFY_POS0 __s, size_t __n,
| ^
/nix/store/f9y6ld56r5lpp6lcg6w865rghclf3yv7-gcc-14.3.0/include/c++/14.3.0/ext/string_conversions.h:113:32: note: called from here
113 | const int __len = __convf(__s, __n, __fmt, __args);
| ^
make: *** [/build/ccBmNLOp.mk:86: /build/ccoJfonD.ltrans28.ltrans.o] Error 1
make: *** Waiting for unfinished jobs....
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/nix/store/hs52m3pqfjcx4a9wzd26mrq1zh09nnai-binutils-2.44/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
| 14:11:35 |
matthewcroughan | * On native musl (no llvm), I get this from nix-expr
[35/35] Linking target libnixexpr.so
FAILED: [code=1] libnixexpr.so
g++ -o libnixexpr.so libnixexpr.so.p/meson-generated_.._parser-tab.cc.o libnixexpr.so.p/meson-generated_.._lexer-tab.cc.o libnixexpr.so.p/attr-path.cc.o libnixexpr.so.p/attr-set.cc.o libn>
/nix/store/24dkhnp0rpb1hvzx1h5frsbfjmgjfpk9-fortify-headers-1.1alpine3/include/stdio.h: In function ‘__to_xstring.constprop’:
/nix/store/24dkhnp0rpb1hvzx1h5frsbfjmgjfpk9-fortify-headers-1.1alpine3/include/stdio.h:80:28: error: inlining failed in call to ‘always_inline’ ‘vsnprintf’: function body can be overwritte>
80 | _FORTIFY_FN(vsnprintf) int vsnprintf(char * _FORTIFY_POS0 __s, size_t __n,
| ^
/nix/store/f9y6ld56r5lpp6lcg6w865rghclf3yv7-gcc-14.3.0/include/c++/14.3.0/ext/string_conversions.h:113:32: note: called from here
113 | const int __len = __convf(__s, __n, __fmt, __args);
| ^
make: *** [/build/ccBmNLOp.mk:86: /build/ccoJfonD.ltrans28.ltrans.o] Error 1
make: *** Waiting for unfinished jobs....
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/nix/store/hs52m3pqfjcx4a9wzd26mrq1zh09nnai-binutils-2.44/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
| 14:12:30 |
dramforever | how on earth is it different on llvm and gcc | 14:14:32 |
matthewcroughan | Maybe it just fails earlier, I had --keep-going on but didn't spot it | 14:14:50 |
matthewcroughan | on native musl, I don't see nix-util in the graph even | 14:15:56 |
matthewcroughan |  Download image.png | 14:15:58 |
dramforever | but we definitely build nix against musl right? | 14:16:12 |
matthewcroughan | I guess it comes later, so yeah nix-expr fails first, before I can get a look at nix-util | 14:16:15 |
dramforever | * but we definitely build nix with musl right? | 14:16:20 |
matthewcroughan | it has worked a lot in the past yeah, though atm it's failing | 14:16:26 |
matthewcroughan | I've never had an issue with it until this experiment | 14:16:40 |
dramforever | well maybe close_range is new | 14:17:01 |
matthewcroughan | looks like 2024 according to blame | 14:17:21 |
dramforever | no look https://hydra.nixos.org/job/nix/master/buildStatic.nix-cli.x86_64-linux | 14:17:23 |
matthewcroughan | ericsson was refactoring | 14:17:24 |
dramforever | it's working | 14:17:35 |
matthewcroughan | static and musl aren't the same are they? | 14:17:37 |