Hi Samuel, Thanks a lot for the feedback
I have also created a WIP pr at https://github.com/dlang/dmd/pull/22829 and have been fixing many there with lots helpful feedback and comments. The current status is that on both i686 and x86_64 all dmd compiler tests pass. For druntime only 2 tests still segfault and 1 is expectedly failing because of the libc stubs. There are some more test errors in the standard library where I have not looked to closely yet. Mar 29, 2026, 17:41 by [email protected]: > > >> 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. > I have since changed this to a simple forward declaration. >> 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... > I guess the reason is that it is unreasonable to require libc headers for all the various supported operating systems > 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. > That might be a bit difficult to do. In general it seems expected that files in the core.sys.OS "namespace" are specific to the os. core.sys.linux.dlfcn also seems to be used for linux + musl and bionic/android >> 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? > I got a compilation error on that file because it is only guarded by CRuntime_Glibc. I added an extra check for linux instead. >> + 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; >> + } >> > > thanks, I have added it. The test that compares struct layouts also missed this. >> + static if ( __USE_FILE_OFFSET64 ) >> > > Do the linux part use such ifs? > yes, but it is even more of an ifdef soup because it has versions for each linux architecture. > Samuel >
