>> [...]
>> So currently my best hunch about the problem is that there was a bug
>> in versioning getmntinfo, or that rust calls the wrong version of
>> getmntinfo, and gets the new statvfs struct where all the char fields
>> are moved around by 16 bytes, but parses it using the old struct
>> definition, and chaos ensues.
>
> I think you're right. With the `struct statvfs' from NetBSD-9.x
> (which is what Rust's copied), rust's libc would have to call
> `__getmntinfo13()' on NetBSD-10+. If you compiled that crate,
> or your program on 10+, then `__getmntinfo90()' is what will
> called, and that will expect the newer structure.
>
> NetBSD compat bits are to allow (older) binaries to run on
> newer OS versions. It won't help in this case, where you're
> compiling on 10+ and a) using a structure from 9.x in a 10.x
> syscall.
>
> I suspect you won't see any issues if you compile both your
> code and the libc crate on 9.x, then bring _that_ binary into
> -HEAD (even) and run it there.
NetBSD 9.2 also has
#ifndef __LIBC12_SOURCE__
int getmntinfo(struct statvfs **, int) __RENAME(__getmntinfo13);
#endif /* __LIBC12_SOURCE__ */
in it's /usr/include/sys/statvfs.h (when, if ever, does
__LIBC12_SOURCE__ get defined?), so redirecting getmntinfo to
__getmntinfo13 as Thomas said via
+ #[link_name = "__getmntinfo13"]
pub fn getmntinfo(mntbufp: *mut *mut crate::statvfs, flags: c_int) ->
c_int;
is probably a workable cure for both 9.x and 10.x. getvfsstat()
should get a similar treatment. The "struct statvfs" in that
same header file looks like the one in rust's libc crate.
> Some Rust `#cfg[]' magic is certainly reqd...
Perhaps we can avoid that, then, since we don't even pretend to
be able to build rust for 8.x or earlier?
Regards,
- Håvard
