Re: git: d549de769055 - main - libc: Remove readdir_r(3) [This broke building rust 1.88]

On Thu, Sep 11, 2025 at 9:48 AM Alan Somers <asomers@freebsd.org> wrote:

> On Thu, Sep 11, 2025 at 9:45 AM Toomas Soome <tsoome@me.com> wrote:
>
>>
>>
>> On 11. Sep 2025, at 18:10, Mark Johnston <markj@FreeBSD.org> wrote:
>>
>> On Thu, Sep 11, 2025 at 05:01:16PM +0200, Dag-Erling Smørgrav wrote:
>>
>> Alan Somers <asomers@freebsd.org> writes:
>>
>> Dag-Erling Smørgrav <des@freebsd.org> writes:
>>
>> Tell that to the Rust developers.  They have been repeatedly warned
>> against using readdir_r(3) for years, as far back as 2016.
>>
>> Have they?  Looking at rust's github page, I see discussions about
>> using readdir_r on Fuchsia and Linux, but nothing about BSD.
>>
>>
>> If you look at these tickets, there are people pointing out that
>> readdir_r() doesn't work correctly even on platforms where it isn't
>> formally deprecated.  The Rust developers chose to fix the Linux case
>> because it produced a link-time warning and ignored the rest.  That's on
>> them.
>>
>> They also seem to be providing their own prototype for readdir_r(),
>> which suppresses the deprecation warning they should be getting on
>> FreeBSD 15, and turns the issue from a failure to compile into a failure
>> to link.  That's also on them.
>>
>>
>> It doesn't really matter whose responsibility it is.  If rust can't be
>> compiled on FreeBSD after a FreeBSD change, then it's up to us to fix
>> it.  The purpose of FreeBSD, like any other useful OS, is to run the
>> software that people want to run.
>>
>> +1 to Alan's request to back out the change for now.
>>
>>
>>
>> How about putting up pull request for rust to fix it?;)
>>
>
> That should certainly be done.  I'll try to do it this weekend, if I have
> time.  However, the need to revert this change will remain.  FreeBSD 15
> needs the ability to run both current and old Rust toolchains.
>

So for current rust: it needs a pull request despite the revert. Rust is
simply wrong here, due to their choices, and that has to be unwound in
their code base. That's non-negotiable. We learned with the FreeBSD11 ABI
troubles that we must be more proactively involved to see changes through
to the end with Rust or the long legacy that creates problems for us. Here
the risk extends beyond the rust ecosystem because we must continue to
expose a broken-by-design interface to newly built code.

Old rust toolchains run fine on 15. Regression testing can be done on
those, but that's not a fully desirable answer. But t's only previously
built rust toolchains that still run. Newly built ones do not. That's a
problem.

So, for building these old toolchains anew, we can't support them
indefinitely. There needs to be a transition period for building old
toolchains. We're in that now that the base change has been reverted. But
the question is: How far back does Rust test? How old are the toolchains
they do A/B testing against today? Is it 3 months? 6 months? 12 months?
That will tell us the timeline we need to support this configuration. Given
both the importance of Rust, and "history" we owe it to ourselves to be
intentional about what we do here.

Warner