WIP: Port dmd and druntime to GNU/Hurd by yelninei · Pull Request #22829 · dlang/dmd

yelninei · 2026-03-27T16:06:24Z

Hi,

As announced on https://forum.dlang.org/thread/agrrykgbdsjlbsgjtatq@forum.dlang.org here is my WIP PR for porting druntime and dmd to GNU Hurd.

To be able to build also #22787 is needed.

Things that I know are still a bit of a mess:

Indentation
How to add version(linux) where CRuntime_Glibc is used to mean linux + glibc.
Mix of new and old alias syntax. Some of the parts were originally against gcc-11 to be able to bootrap and I have not revised the patches yet.

I am currently quite happy with the dmd part as all tests pass on 32bit and 64bit except

dmd/compiler/test/dshell/sameenv.d : checks that 2 executables have the same environment variables but they expectedly differ in LD_ORIGIN_PATH
dmd/compiler/test/runnable_cxx/cppa.d : A warning coming from non _GLIBCXX_USE_CXX98_ABI version

For the runtime some tests still crash in pthread_join, I am not entirely sure why as the same test outside of libdruntime_ut works fine.
On x86_64 the test runner gets killed after a while with the gc suspend signal, I dont know yet why the runtime does not handle it.

I am not erntirely sure about the format for the dmd triplet as it differs from both the gnu config and llvm triplet.

I have asked people on the bug-hurd mailing list for help as well
https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00274.html
https://lists.gnu.org/archive/html/bug-hurd/2026-03/msg00275.html

There are some more things needed to bring this back into gdc,

dlang-bot · 2026-03-27T16:06:27Z

Thanks for your pull request and interest in making D better, @yelninei! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
I have provided a detailed rationale explaining my changes
New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#22829"

yelninei · 2026-03-27T16:58:45Z

The error from the circleci is

ERROR: Newly generated header file (/home/circleci/dmd/generated/linux/release/64/frontend.h) doesn't match with the reference header file (/home/circleci/dmd/compiler/src/dmd/frontend.h)

DETAILS:

diff --git a/home/circleci/dmd/compiler/src/dmd/frontend.h b/home/circleci/dmd/generated/linux/release/64/frontend.h
index 8e8e2fe76..479667814 100644
--- a/home/circleci/dmd/compiler/src/dmd/frontend.h
+++ b/home/circleci/dmd/generated/linux/release/64/frontend.h
@@ -7363,8 +7363,9 @@ struct Target final
         FreeBSD = 16u,
         Solaris = 32u,
         DragonFlyBSD = 64u,
-        all = 127u,
-        Posix = 125u,
+        Hurd = 128u,
+        all = 255u,
+        Posix = 253u,
     };
 
     OS os;

===============
The file `src/dmd/frontend.h` seems to be out of sync. This is likely because
changes were made which affect the C++ interface used by GDC and LDC.

I guess this is expected, is there a way to regenerate the header?

pbackus · 2026-03-27T17:30:42Z

Re: regenerating the headers, if you read a few more lines down in that error message, you will see this:

To read more about frontend.h and its usage, see src/README.md#cxx-headers-test

Which refers to https://github.com/dlang/dmd/tree/master/compiler/src#cxx-headers-test

ibuclaw · 2026-03-27T19:41:39Z

I am not erntirely sure about the format for the dmd triplet as it differs from both the gnu config and llvm triplet.

I thought dmd triplet (tuples?) matched ldc.

Historically, I guess gnu/hurd would be i*86-gnu or x86_64-gnu.

compiler/src/dmd/backend/arm/cod1.d

druntime/src/core/internal/elf/dl.d

druntime/src/core/internal/elf/io.d

druntime/src/core/stdc/config.d

druntime/src/core/sys/hurd/dlfcn.d

druntime/src/core/sys/hurd/elf.d

ibuclaw · 2026-03-27T20:00:19Z

druntime/src/core/sys/hurd/execinfo.d

+/**
+ * D header file for GNU Hurd
+ *
+ * Copyright: Copyright Martin Nowak 2012.


Wrong year, wrong copyright. :-)

If unsure, please use:

Copyright: Copyright (c) 2026 D Language Foundation

ibuclaw · 2026-03-27T20:01:46Z

druntime/src/core/sys/hurd/execinfo.d

+ *
+ * Copyright: Copyright Martin Nowak 2012.
+ * License:   $(LINK2 http://www.boost.org/LICENSE_1_0.txt, Boost License 1.0)
+ * Authors:   Martin Nowak


I assume Martin didn't author this module.

The file is a copy paste of the linux version with s/linux/hurd/

Is that enough to void the original copyright as it is clearly a derivative?

I'm not qualified to say. In isolation, I don't consider the file big enough to warrant any copyright claim.

Rather, the body of work as a whole (this PR) ought to be considered as authored by the contributor.

ibuclaw · 2026-03-27T20:06:39Z

druntime/src/core/sys/hurd/unistd.d

@@ -0,0 +1,25 @@
+module core.sys.hurd.unistd;


Some modules are missing comment headings/notices entirely. Others have inconsistent styles.

As these are newly introduced sources, I'd err towards not repeating previous bad habits, and pick one format, and use it consistently throughout all new files.

druntime/src/core/sys/linux/stdio.d

ibuclaw · 2026-03-27T20:19:48Z

druntime/src/core/sys/posix/sys/ioctl.d

 }
+else version (Hurd)
+{
+  // What is needed here?


Any part of ioctls.h or ioctl-types.h that would be needed to interact with ioctl().

druntime/src/core/sys/posix/sys/socket.d

ibuclaw · 2026-03-27T20:26:07Z

druntime/src/core/sys/posix/pthread.d

 version (CRuntime_Glibc)
 {
+  version (linux)
+  {


It looks like the outer CRuntime_Glibc is unneeded here. Just version (linux) { } else version (Hurd) { } else ... ?

Not sure, that would shadow the musl, uclibc and bionic versions on linux which are not 1:1 copies of the glibc one

ibuclaw · 2026-03-27T20:27:26Z

druntime/src/core/sys/posix/pthread.d

 version (CRuntime_Glibc)
 {
+  version (linux)


Likewise, maybe just remove the CRuntime_Glibc guard.

druntime/src/rt/sections_elf_shared.d

druntime/src/core/time.d

yelninei · 2026-03-28T08:25:07Z

I am not erntirely sure about the format for the dmd triplet as it differs from both the gnu config and llvm triplet.

I thought dmd triplet (tuples?) matched ldc.

For llvm the triplet would be *-*-hurd-gnu for gcc just *-*-gnu.

The thing that confuses me is that *-*l-inux-gnu would be *-*-linux-glibc for dmd -target flag.

Historically, I guess gnu/hurd would be i*86-gnu or x86_64-gnu.

Currently the match for both -os and -target is hurd everywhere to match the Hurd version.

All this confusion etc is why i am askingas it does not match to the triplets for gcc and llvm that are already used.

i think llvm added hurd as the osname to not confuse gnu for the libc in use, especially in D there is GNU version already for libstdc++ which creates even more ambiguity.

Edit: The merge conflict i just resolved in the documentation for -target mentions gnu is accepted for glibc, but looking at ParseCEnv this does not seem to be the case.

As some people might epect "gnu" to specifiy the libc leaning on the llvm side with hurd-gnu might be more reasonable

yelninei · 2026-03-28T08:45:39Z

compiler/src/dmd/backend/cdef.d

                         EX_FREEBSD | EX_FREEBSD64 |
                         EX_SOLARIS | EX_SOLARIS64 |
                         EX_OPENBSD | EX_OPENBSD64 |
+                         EX_HURD    | EX_HURD64    |


Should this be below the dragonflybsd case?

as trhere is no 32bit one it looks a bit weird

Looks shouldnt matter. But also neither does order.

yelninei · 2026-03-28T08:46:15Z

compiler/src/dmd/backend/cdef.d

                EX_SOLARIS64 |
                EX_OPENBSD64 |
+                EX_HURD64    |
                EX_DRAGONFLYBSD64;


same, for symmtry with the 32bit case i added after openbsd but maybe it should be at the end?

yelninei · 2026-03-28T08:47:00Z

compiler/src/dmd/dmdparams.d

            os =  Target.OS.OpenBSD;
        else if (matches("linux"))
            os =  Target.OS.linux;
+        else if (matches("hurd")) // "gnu"?


what should be the match for the os here?

This is fine

compiler/src/dmd/target.d

druntime/src/core/sys/posix/sys/types.d

compiler/src/dmd/target.d

compiler/test/runnable/test22.d

yelninei · 2026-03-28T11:34:47Z

I ran detab everywhere, cleaned up a lot of things manually and then also ran dfix for the alias conversion (separate commit to make it easier to backport to earlier versions)

some things remain (especially where i need guard off linux code as that would also need to be reindented)

compiler/test/runnable/test22.d

druntime/src/core/sys/posix/sys/stat.d

yelninei · 2026-03-29T11:54:45Z

EDIT:

Adding the GCSignalsUnblock version for the gc fixes a lot more issues. The pthread ones remain.

This was not great to debug.

Followup to 90772c4.

ibuclaw · 2026-03-30T20:22:14Z

compiler/src/dmd/target.d

+            version (CRuntime_Glibc)
+                runtime = Runtime.Glibc;
+            else
+                assert(0);


Suggested change

version (CRuntime_Glibc)

runtime = Runtime.Glibc;

else

assert(0);

runtime = Runtime.Glibc;

I would just unconditionally set runtime as glibc.

Version doesn't make sense here for cross compilation purposes.

ibuclaw · 2026-03-30T20:47:38Z

EDIT:

Adding the GCSignalsUnblock version for the gc fixes a lot more issues. The pthread ones remain.

This was not great to debug.

I wrote that code, and it was not great debugging (proprietary) solaris either. :-)

Is Hurd's fork implemented in glibc?

yelninei · 2026-03-31T09:29:52Z

Is Hurd's fork implemented in glibc?

yes, see glibc/sysdeps/mach/hurd/_Fork.c

the main issue was that things like rmdir and read would crash and finding out about that the version exists and someone has already solved this.
I cant imagine what it would be like first finding out what the problem is in the first place.

yelninei · 2026-03-31T09:34:40Z

One thing for gdc how do these files map to dmd or are these gdc specific?

libphobos/libdruntime/config/common/threadasm.S
libphobos/libdruntime/config/x86/switchcontext.S
threadasm.S: Adding __GNU__ for note.GNU-stack
switchcontext.S: guarding against __MACH__ by additional __APPLE__

yelninei force-pushed the dmd-hurd branch from e08d353 to 90c7a07 Compare March 27, 2026 16:10

yelninei mentioned this pull request Mar 27, 2026

WIP: phobos: Fixes for GNU/Hurd. dlang/phobos#10980

Draft

yelninei force-pushed the dmd-hurd branch from 90c7a07 to 0843c6b Compare March 27, 2026 17:55