Hello,
yelninei--- via Bug reports for the GNU Hurd, le ven. 27 mars 2026 16:43:51
+0100, a ecrit:
> - linker stub warnings:
> The following linker stub warnings are emitted:
> sched_get_priority_min
> sched_get_priority_max
> pthread_setschedprio
> (pthread_setschedparam)
>
> should something be done about these (e.g. there is already a workaround for
> priority for netbsd in osthread.d) or should this just be left alone for now?
They can be left alone, it's not really important for things to work.
> - I am not entirely sure where to put the pthread enum types. These are
> shared between "core.sys.posix.sys.types" and "core.sys.posix.pthread" i put
> them in core.sys.hurd.sys.types for now.
I guess you can follow what other OSes are doing?
> Also not sure what to do with the internal __pthread struct. I followed what
> is done in rustc, if there is a better solution let me know.
You don't need to actually express something, as applications are not
supposed to access it, so leaving as a dumb content so one can create
pointers to it is fine.
> - The runtime by default uses SIGRTMIN and SIGRTMIN +1 as the suspend/resume
> signals for its garbage collector. As these are not supported I changed them
> back to SIGUSR1 and SIGUSR2.
Yes, you needed so.
> diff --git a/druntime/src/core/stdc/errno.d b/druntime/src/core/stdc/errno.d
> index db347e404b..6a4745f2b0 100644
> --- a/druntime/src/core/stdc/errno.d
> +++ b/druntime/src/core/stdc/errno.d
> @@ -2457,6 +2457,113 @@ else version (WASI)
> enum ERFKILL = 132;
> enum EHWPOISON = 133;
> }
> +else version (Hurd)
> +{
> + enum EPERM = 0x40000001; /* Operation
> not permitted */
> + enum ENOENT = 0x40000002; /* No such file
> or directory */
> + enum ESRCH = 0x40000003; /* No such
> process */
> + enum EINTR = 0x40000004; /* Interrupted
> system call */
> + enum EIO = 0x40000005; /* Input/output
> error */
Eeww, why are languages doing that instead of just picking the values
from headers...
> diff --git a/druntime/src/core/stdc/limits.d b/druntime/src/core/stdc/limits.d
> index 2684b22bfc..35ee96a052 100644
> --- a/druntime/src/core/stdc/limits.d
> +++ b/druntime/src/core/stdc/limits.d
> @@ -181,5 +181,19 @@ else version (Windows)
> ///
> enum PIPE_BUF = 5120;
> }
> +else version (Hurd)
> +{
> + // no arbitrary fixed limits
> + ///
> + // enum MAX_CANON
> + ///
> + // enum MAX_INPUT
> + ///
> + enum NAME_MAX = 255;
Yes, that one indeed is a limitation of the ABI.
> + ///
> + // enum PATH_MAX
> + ///
> + // enum PIPE_BUF
> +}
> else
> static assert(0, "unsupported OS");
> +++ b/druntime/src/core/sys/hurd/dlfcn.d
Mmmm, that dlfcn is actually the glibc dlfcn, there is nothing
hurd-specific here, we would probably want to shared it with the linux
part.
> +++ b/druntime/src/core/sys/hurd/elf.d
And similarly.
> +++ b/druntime/src/core/sys/hurd/link.d
And similarly.
> diff --git a/druntime/src/core/sys/linux/stdio.d
> b/druntime/src/core/sys/linux/stdio.d
> index 2d079fd71f..c06184ab8a 100644
> --- a/druntime/src/core/sys/linux/stdio.d
> +++ b/druntime/src/core/sys/linux/stdio.d
> @@ -9,7 +9,7 @@ module core.sys.linux.stdio;
> version (CRuntime_Glibc):
> public import core.sys.posix.stdio;
> import core.sys.posix.sys.types : ssize_t, off64_t = off_t;
> -import core.sys.linux.config : __USE_FILE_OFFSET64;
> +import core.sys.posix.config : __USE_FILE_OFFSET64;
> import core.stdc.stdio : FILE;
> import core.stdc.stddef : wchar_t;
Is that related?
> + struct flock
> + {
> + short l_type;
> + short l_whence;
Note that on the i386 it was (wrongly) an int. We'd need to have it int
here in the i386 case.
> + off_t l_start;
> + off_t l_len;
> + pid_t l_pid;
> + }
> + static if ( __USE_FILE_OFFSET64 )
Do the linux part use such ifs?
Samuel
