[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Prompt presented to Google Gemini about compiling Rust in GNU/Hurd



Hello,

Jose Luis Alarcon Sanchez, le lun. 27 oct. 2025 14:41:49 +0100, a ecrit:
> I found the report she provided in response to be so comprehensive and
> in-depth that I want to present it to the List,

Unfortunately it is usual AI production: a lot of common sense, but also
a lot of misled statements, for instance:

> In the Hurd model, core services are implemented as a collection of
> user-space servers,
[...]
> user and group management, are not direct kernel calls but involve
> inter-process communication (IPC) with these specialized servers. This
> complex structure means that defining a robust and feature-complete
> C FFI layer, especially for retrieving extensive metadata from
> structures like passwd, is inherently more challenging than on
> monolithic systems.

The libc structures exposed by glibc are essentially the same on Linux
and on GNU/Hurd. The fact that GNU/Hurd uses translators does not have
anything to do with the C portability questions.

[...]
> On Hurd, the Glibc implementation must interface with the Mach/Hurd
> servers.

Yes, but

> This constraint leads to subtle but fatal differences in the system
> structs exposed to FFI wrappers like uzers.

No: that's not exposed in the libc interface.

> Prior analyses of Debian GNU/Hurd build failures confirm that
> packages frequently fail due to missing constants (like PATH_MAX,
> MAXHOSTNAMELEN)

That has nothing to do with RPCs, and they are not missing, they are
optional.

Here, the problem is probably rather than the crate detects the hurd
port as both being a unixish system and a bsd system, and thus tries to
define for both cases.

Samuel


Reply to: