You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #1922, I added clock_nanosleep to libc for FreeBSD 12. I intentionally avoided adding it to FreeBSD 11 because it was added in FreeBSD 11.1. I read #570 and #1518, but it isn't clear to me what libc's policy is on support for EOL releases like FreeBSD 11.0, discontinued in 2017.
This question is phrased generally, but I'm looking to add clock_nanosleep to libc's freebsd 11 target so I can merge nix-rust/nix#1315
The issue of changes from one version of an OS/libc to the next seem complicated, but I think this issue is significantly less complicated. I don't want to build for FreeBSD after 11 - I want to build for 11.1, which might just be included in the freebsd11 cfg.
Given the relative range of support Rust currently offers, and that FreeBSD11 only takes us about 5 years back, and not, say, 25, I would think it would not be unreasonable to add support for an API for FreeBSDv11 that is still supported in current versions of FreeBSD, because it's not like we're adding support for a deprecated API then, but I don't have the final say.
11.4 is the oldest currently supported version of FreeBSD. No user should be using anything older, and libc shouldn't try to support anything older than 11.4
libc's CI tests on FreeBSD 11.4, not 11.0. So CI won't complain.
Even if somebody does try running a Rust executable on FreeBSD 11.0 built using a version of libc that contains the clock_nanosleep function, nothing bad will happen unless they actually try to execute clock_nanosleep.
Reacted by David CARLIER, Conrad Meyer and Jubilee
Triage: we nowadays remove EoL versions of FreeBSD on CI (thanks to contributors!), which means the crate doesn't support such a version officially, but it might work unless we introduce any breaking changes.
Activity
workingjubilee commentedon Feb 23, 2021
This appears to bump up against #2061, wherein we found out that building for FreeBSDs after 11 is actually secretly mostly a dead letter.
maxbla commentedon Feb 24, 2021
The issue of changes from one version of an OS/libc to the next seem complicated, but I think this issue is significantly less complicated. I don't want to build for FreeBSD after 11 - I want to build for
11.1, which might just be included in thefreebsd11cfg.workingjubilee commentedon Feb 24, 2021
Given the relative range of support Rust currently offers, and that FreeBSD11 only takes us about 5 years back, and not, say, 25, I would think it would not be unreasonable to add support for an API for FreeBSDv11 that is still supported in current versions of FreeBSD, because it's not like we're adding support for a deprecated API then, but I don't have the final say.
asomers commentedon Jun 1, 2021
Add it. It will harm nothing.
asomers commentedon Sep 17, 2021
Now FreeBSD 11.4 is EoL. I think we should raise the default ABI to FreeBSD 12. See PR #2406 .
JohnTitor commentedon Dec 19, 2023
Triage: we nowadays remove EoL versions of FreeBSD on CI (thanks to contributors!), which means the crate doesn't support such a version officially, but it might work unless we introduce any breaking changes.