Darling: File Path Issues

[frank-trampe]

The darling shell works for me, and I can navigate around the virtual file system, but I get constant errors about being unable to create the Library folder for the current user via dirstructure.cpp. /Users appears when I ls from / in Darling, but it is not present in ~/.darling. And when I try to mkdir inside /Users in Darling, I get an error about . not existing.

I do know that it's picking up the prefix. Touching a file in ~/.darling in the host environment shows up when I run ls in / in Darling, but creating ~/.darling/Users in the host environment does not fix the . missing error from before.

[bugaevc]

/Users appears when I ls from / in Darling, but it is not present in ~/.darling.

It should not be — we build prefixes on overlayfs now (see #197). /Users is located under /usr/local/libexec/darling/, and it's just a symlink to /home directory on the host (run ls -l / to confirm).

So what it should be doing is creating ~/Library. Check if it's missing some permissions — otherwise, run it under strace, like so:

darling shutdown && sudo strace -f -u $USER darling shell

[frank-trampe]

/usr/local/libexec/darling/Users is a symlink to /Volume/SystemRoot/home, but /Volume does not exist on my system, of course. So I created /Volume and made /Volume/SystemRoot a symlink to /. Still not working. ls /usr/local/libexec/darling/Users/administrator/Library/ works. strace says that it is trying to access the native Macintosh paths like /Users/administrator/.bash_history. Is the darling layer supposed to operate deeper than the system call, or is that wrong?

[LubosD]

darling sets up overlayfs at ~/.darling (which is built on top of /usr/local/libexec/darling) in a mount namespace (so you cannot see it from the outside) and uses pivot_root() to use ~/.darling as its root directory.

/Volumes may not exist on your main root file system, but what matters is that /usr/local/libexec/darling/Volumes exists.

Using mkdir is not allowed inside /Users, but the error you're seeing is strange. This is what you should see:

$ darling shell
Darling [~]$ cd /Users
Darling [/Users]$ ls -l
total 8
drwxr-xr-x  63 lubos  lubos  4096  3 úno 13:42 lubos
Darling [/Users]$ mkdir test
mkdir: test: Permission denied
Darling [/Users]$ cd lubos
Darling [~]$

What kernel version are you using?

[frank-trampe]

Yeah. I'm not getting that result.

Darling [/]$ cd /Users
Darling [/Users]$ ls
Darling: Creating Library structure at /Users/administrator/Library/
Darling: Cannot mkdir(/Users/administrator/Library/): No such file or directory
Darling: Cannot mkdir(/Users/administrator/Library/Application Support): No such file or directory
Darling: Cannot mkdir(/Users/administrator/Library/Assistants): No such file or directory
Darling: Cannot mkdir(/Users/administrator/Library/Audio): No such file or directory
Darling: Cannot mkdir(/Users/administrator/Library/Audio/MIDI Drivers): No such file or directory
...
Darling [/Users]$ ls 2> /dev/null
Darling [/Users]$ exit
exit

I'm on a fairly recent kernel.

Linux xenial-box-1 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[frank-trampe]

I ought to mention that the "Creating library structure" process with errors also happens immediately upon running darling shell. There is no prior error about a mount or an overlay or an access failing, though.

[bugaevc]

creating ~/.darling/Users in the host environment does not fix the . missing error from before.

So I created /Volume and made /Volume/SystemRoot a symlink to /.

You should not create any additional folders yourself; Darling comes with all the files and symlinks you'd need to run it right out of the box. It's a bit complicated because of overlayfs and pivot_root — things are set up to work inside the container; but they don't necessarily have correct meaning when you inspect them from the outside. For example, /usr/local/libexec/darling/Users is a symlink to /Volumes/SystemRoot/home (you missed the s, by the way); there's no such folder on the host system, but that's where the host's root gets mounted inside the container; this way it is a correct symlink inside, but it appears to be broken from outside.

strace says that it is trying to access the native Macintosh paths like /Users/administrator/.bash_history. Is the darling layer supposed to operate deeper than the system call, or is that wrong?

No, apart from /dev/mach stuff that is handled by the kernel module, syscalls that an executable running under Darling makes are already translated and ready for the Linux kernel to process. But again, Darling runs programs in a special container (and the kernel is aware of that, of course), inside of which filesystem layout closely represents that of macOS. You can think of it as of a chroot combined with overlayfs.

Now, start with removing all the additional files (directories, symlinks, whatever) you've created. Next, let's see, maybe your container is not being set up properly. Figure out a PID of any Darling process (do it from the outside, because processes have different PIDs when inspected from inside the container...) and show us the contents of /proc/PID/mounts.

[frank-trampe]

I figured creating /Volumes was wrong and deleted it immediately afterwards. I just wanted to see what changed.

administrator@xenial-box-1:~$ ps -Af | grep darling
adminis+ 30618     1  0 00:30 pts/9    00:00:00 darling shell
adminis+ 30624 29947  0 00:30 pts/9    00:00:00 darling shell
adminis+ 30642 30569  0 00:31 pts/10   00:00:00 grep --color=auto darling
administrator@xenial-box-1:~$ cat /proc/30618/mounts
/dev/sda1 /Volumes/SystemRoot ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
udev /Volumes/SystemRoot/dev devtmpfs rw,nosuid,relatime,size=2003868k,nr_inodes=500967,mode=755 0 0
devpts /Volumes/SystemRoot/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /Volumes/SystemRoot/dev/shm tmpfs rw,nosuid,nodev 0 0
mqueue /Volumes/SystemRoot/dev/mqueue mqueue rw,relatime 0 0
hugetlbfs /Volumes/SystemRoot/dev/hugepages hugetlbfs rw,relatime 0 0
tmpfs /Volumes/SystemRoot/run tmpfs rw,nosuid,noexec,relatime,size=404672k,mode=755 0 0
tmpfs /Volumes/SystemRoot/run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /Volumes/SystemRoot/run/user/108 tmpfs rw,nosuid,nodev,relatime,size=404672k,mode=700,uid=108,gid=114 0 0
gvfsd-fuse /Volumes/SystemRoot/run/user/108/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=108,group_id=114 0 0
tmpfs /Volumes/SystemRoot/run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=404672k,mode=700,uid=1000,gid=1000 0 0
sysfs /Volumes/SystemRoot/sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
securityfs /Volumes/SystemRoot/sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /Volumes/SystemRoot/sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /Volumes/SystemRoot/sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
pstore /Volumes/SystemRoot/sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
debugfs /Volumes/SystemRoot/sys/kernel/debug debugfs rw,relatime 0 0
fusectl /Volumes/SystemRoot/sys/fs/fuse/connections fusectl rw,relatime 0 0
proc /Volumes/SystemRoot/proc proc rw,nosuid,nodev,noexec,relatime 0 0
systemd-1 /Volumes/SystemRoot/proc/sys/fs/binfmt_misc autofs rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
binfmt_misc /Volumes/SystemRoot/proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
overlay / overlay rw,relatime,lowerdir=/usr/local/libexec/darling,upperdir=/home/administrator/.darling,workdir=/home/administrator/.darling.workdir 0 0
proc /proc proc rw,relatime 0 0
administrator@xenial-box-1:~$ cat /proc/30624/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=2003868k,nr_inodes=500967,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=404672k,mode=755 0 0
/dev/sda1 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
tmpfs /run/user/108 tmpfs rw,nosuid,nodev,relatime,size=404672k,mode=700,uid=108,gid=114 0 0
gvfsd-fuse /run/user/108/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=108,group_id=114 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=404672k,mode=700,uid=1000,gid=1000 0 0

[bugaevc]

I figured creating /Volumes was wrong and deleted it immediately afterwards. I just wanted to see what changed.

Remove ~/.darling/Users and anything else you've added too. See if that fixes the issue, by any chance.

[mounts]

That looks normal. The next step is to inspect the filesystem from inside the container using host's tools, like this:

Darling [/]$ /Volumes/SystemRoot/bin/ls -l /
... output...
Darling [/]$ /Volumes/SystemRoot/bin/ls -l /Users
...output...

[frank-trampe]

I removed ~/.darling/Users, made sure that all darling instances were closed, and started it.

Darling [/]$ /Volumes/SystemRoot/bin/ls -l /
total 32
drwxr-xr-x   2 administrator administrator 4096 Jan 28 22:44 Applications
drwxr-xr-x   3 root          root          4096 Jan 28 22:36 System
drwxrwxr-x   0 administrator administrator    0 Jan 28 23:47 Users
drwxr-xr-x   1 administrator administrator 4096 Jan 28 22:44 Volumes
drwxr-xr-x   2 root          root          4096 Jan 28 22:37 bin
lrwxrwxrwx   1 root          root            23 Jan 28 22:36 dev -> /Volumes/SystemRoot/dev
lrwxrwxrwx   1 root          root            11 Jan 28 22:36 etc -> private/etc
lrwxrwxrwx   1 root          root             5 Jan 28 22:36 home -> Users
lrwxrwxrwx   1 root          root            23 Jan 28 22:36 lib -> /Volumes/SystemRoot/lib
lrwxrwxrwx   1 root          root            25 Jan 28 22:36 lib64 -> /Volumes/SystemRoot/lib64
drwxr-xr-x   1 administrator administrator 4096 Jan 28 22:44 private
dr-xr-xr-x 154 root          root             0 Feb  4 06:30 proc
drwxr-xr-x   2 root          root          4096 Jan 28 22:37 sbin
lrwxrwxrwx   1 root          root            11 Jan 28 22:36 tmp -> private/tmp
drwxr-xr-x   1 administrator administrator 4096 Jan 28 22:44 usr
lrwxrwxrwx   1 root          root            11 Jan 28 22:36 var -> private/var
Darling [/]$ /Volumes/SystemRoot/bin/ls -l /Users
total 0

[bugaevc]

It looks like either ~/.darling/Users is still there or you failed to kill Darling properly. Use darling shutdown from the host to do the latter.

[frank-trampe]

Hey, it works! I don't know how I got into this death loop before, since I only started creating directories and symlinks to work around that problem. Thanks very much.

What does darling shutdown do that killall darling doesn't?

[bugaevc]

It kill -9s the prelaunchd, if that makes any sense. The thing is prelaunchd is going to exec the real launchd in the future, but for now it only loops reaping zombies — and it sets up its mask to ignore other signals, so we have to kill -9 it. darling shutdown is for now just a convenient wrapper around our "find prelaunchd and verify it's the right one" machinery and brutally killing it. When we have launchd working, it will ask launchd to shut down instead of killing it.

[frank-trampe]

Ah. That makes sense.

[frank-trampe]

One more question. Sometimes darling tries to access the home directory with the name administrator.darling instead of just administrator, and that fails. Is there a setting wrong somewhere?

Darling [~/Downloads]$ hdiutil attach commandlinetoolsosx10.10forxcode6.3.2.dm>
Cannot mkdir /Users/administrator.darling/Volumes/commandlinetoolsosx10.10forxcode6.3.2
Darling [~/Downloads]$ pwd
/Users/administrator/Downloads
Darling [~/Downloads]$ ls /Users
administrator

[bugaevc]

You are probably using an older version of Darling that doesn't yet have my recent hdiutil fixes/updates (see #247). Just update/rebuild/reinstall and it should work.

(Note that to update, you need to

$ git pull
$ git submodule init
$ git submodule update

Also, make sure to shut down the container before reinstalling.)

[bugaevc]

To clarify, it was supposed to use the outside-of-container path to /Volumes (before my changes), which is $DPREFIX/Volumes, and when $DPREFIX is not set, it tried to use $HOME/.darling, but there's probably a slash missing somewhere.

Anyway this old scheme doesn't work since the introduction of the Darling container, and I recently changed it to just access /Volumes.

[frank-trampe]

Okay. I'll try that. This project sure moves quickly.

[frank-trampe]

Sorry to bother you again, but there's another small issue. I was trying to run npm, which apparently requires access to page 0. When I ran the sudo setcap cap_sys_rawio=ep /usr/local/bin/dyld64 command, darling shell stopped working.

/Volumes/SystemRoot/usr/local/bin/dyld64: error while loading shared libraries: libdyld.so: cannot open shared object file: No such file or directory

I tried adding a special ld.so.conf.d entry for /usr/local/lib/x86_64-linux-gnu/darling/ (already having created one for /usr/local/lib/x86_64-linux-gnu/ to get Darling working originally), but I still got the same error. Removing the capability entry for /usr/local/bin/dyld64 got darling shell working again.

I understand that executables with setpcap can't use LD_LIBRARY_PATH, but I don't understand why my ld.so.conf.d hack isn't working. Is there another known work-around?

[bugaevc]

This is a known issue; truth is I don't know myself why it doesn't work with ld.so.conf.d (spent like two days on trying to figure that out, to no avail), so I added LD_LIBRARY_PATH as a temporary workaround -- temporary, because with much anticipated Mach-O transition (see #221 -- though the last post there is very outdated) a whole bunch of hacks, including this one, will go away.

Yes, setcap is the problem with this workaround. Fortunately, most programs work fine without page 0 mapped, even though Darling warns you they need it.

[frank-trampe]

Node crashes, unfortunately.

/usr/local/bin/node[14]: ../src/node.cc:4239:void node::PlatformInit(): Assertion `(0) == (sigaction(nr, &act, nullptr))' failed.
Abort trap: 6 (core dumped)

I might need to compile node with that disabled, but I'll explore other options first.

[bugaevc]

You better debug what's happening, e.g. look at strace for signal/sigaction calls.

[LubosD]

This looks like a simple incompatibility. I'll take a look at it.

[bugaevc]

cc @frank-trampe

[LubosD]

I've fixed this problem, but now it immediately terminates with exit code 11. It spawns a child process, which gets SIGSEGV:

[pid 14027] mmap(NULL, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f452662a000
[pid 14027] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7f4526629bb8} ---
[pid 14028] +++ killed by SIGSEGV +++
[pid 14027] +++ killed by SIGSEGV +++

This will be "fun" to debug :-D

[LubosD]

Node.js now seems to run. There is something wrong with pthread_attr_setstack() on current Debian Testing. The man page for this function clearly states:

stackaddr should point to the lowest addressable byte of a buffer of stacksize bytes that was allocated by the caller.

and this is how it has behaved on my Gentoo. But on my Debian system, stackaddr is treated as the highest stack address (i.e. where the stack starts, since stacks grown down). Screw it, I'm letting libpthread allocate the smallest possible stack (1 page) and then we just jump to our own proper stack. That should be sufficiently portable.

[frank-trampe]

@LubosD, nodejs runs for me now, but it's a bit fragile (crashes on double-SIGINT) , and npm crashes when running update.

Darling [~/appium]$ npm update      
Cannot map page zero, some macOS apps may require this.
This problem can be fixed by running 'setcap cap_sys_rawio=ep /Volumes/SystemRoot/usr/local/bin/dyld64' as root.
Abort trap: 6 (core dumped)

I feel bad about dumping all of this on you guys. Is there any way I can help? What does a debugging environment for darling look like?

[LubosD]

@frank-trampe As long as we can reproduce the problem, it's a lot easier if we handle it ourselves. We do have gdb-darling, but it's not yet working 100% and it's only designed to work with one of our development branches.

The next failure is probably also simple:

$ darling bin/node bin/npm update
Assertion failed: (process_title.len + 1 == size), function uv_setup_args, file ../deps/uv/src/unix/proctitle.c, line 53.

[frank-trampe]

Well as long as you fellows are willing to do all the work, there will be no complaints from me!

[LubosD]

So the issue is trivial, but I'm at a loss currently. The thing is the development branch (using-machos-experiment) wouldn't ever suffer from this incompatibility, so I'm a bit reluctant to fix it in master. Maybe it's better to invest the time in bringing the development branch closer to merging into master instead.

[frank-trampe]

Even if I knew enough to set priorities, I have no right to do so. I am immensely grateful for your help, though.

Here's another quirk. Running the iPhone simulator trips an error in dyld trying to find a symbol in libCFFExtra.so, but, since it relates to exception handling, there seems to be some other error triggering that one.

<atforms/iPhoneSimulator.platform/Developer/usr/bin/xcrun simctl
Cannot map page zero, some macOS apps may require this.
This problem can be fixed by running 'setcap cap_sys_rawio=ep /Volumes/SystemRoot/usr/local/bin/dyld64' as root.
Cannot map page zero, some macOS apps may require this.
This problem can be fixed by running 'setcap cap_sys_rawio=ep /Volumes/SystemRoot/usr/local/bin/dyld64' as root.
dyld: Cannot execute binary file: Symbol not found: _OBJC_EHTYPE_$_NSException (expected in libCFFExtra.so) when loading DTXConnectionServices
<oper/usr/bin/xcrun instruments -w "iPhone 5 (8.0 Simulator)"                
Cannot map page zero, some macOS apps may require this.
This problem can be fixed by running 'setcap cap_sys_rawio=ep /Volumes/SystemRoot/usr/local/bin/dyld64' as root.
Cannot map page zero, some macOS apps may require this.
This problem can be fixed by running 'setcap cap_sys_rawio=ep /Volumes/SystemRoot/usr/local/bin/dyld64' as root.
dyld: Cannot execute binary file: Symbol not found: _OBJC_EHTYPE_$_NSException (expected in libCFFExtra.so) when loading DTXConnectionServices

[frank-trampe]

Hi guys. I don't mean to be pushy, and I'm deeply grateful that Darling exists at all, but these two things are blocking issues for a project of mine. Are there any notes on debugging in a Darling container that might help me be useful here?

[bugaevc]

Hi, on the master branch you can debug with a regular gdb running outside of the container — just make sure to figure the right PID and attach to it — you may need to attach to the shell first and then follow it through the fork/exec process.

I doubt you're going to find anything useful here though. Does the iPhone simulator need GUI? If so, you're out of luck, because GUI apps are not supposed at the moment. As for DTXConnectionServices, I believe XPC stuff is not fully implemented yet, so no wonder it's failing.

What might be interesting here is the problem with NSException — I'm sure it is working in some cases, and here it's not found at all.

[frank-trampe]

Okay. I'll fiddle with gdb tomorrow.

The iPhone simulator does not require GUI (at least for my intended use). I've never heard of DTXConnectionServices, and the Google results are non-informative. What do they do? Are they kernel-side, or could I copy some frameworks from a working Macintosh system?

[bugaevc]

Actually gdb may not be that useful here (read on).

I've never heard of DTXConnectionServices, and the Google results are non-informative. What do they do?

Neither have I. Google gives us the following: _From what I can tell DTX wraps XPC communication with Xcode IDE features._

Are they kernel-side, or could I copy some frameworks from a working Macintosh system?

No. It's a private framework bundled with Xcode.app (Xcode.app/Contents/SharedFrameworks/DTXConnectionServices.framework) -- you do have it already, but you get the error when dyld tries to load it.

The error tells us that DTXConnectionServices expect to find a symbol named _OBJC_EHTYPE_$_NSException in Foundation Kit, but it's not present in Darling's/GNUstep implementation. There's not much to _debug_ -- more to research what _OBJC_EHTYPE_ is exactly and why it's present in Apple's Foundation but not there in ours -- maybe because __attribute__((objc_exception)) is missing on NSException?

[LubosD]

@bugaevc Darling's libdyld should automatically handle EHTYPE symbols, maybe the regexp is broken?

[bugaevc]

Hmm, static std::regex g_reObjcEhSymbol("OBJC_EHTYPE_.+") seems correct (barring the initial underscore, as usual).

@frank-trampe If you want to debug, this piece of code should work, but it seems it doesn't.

[LubosD]

FYI: Node.js seems to work OK with current Darling master.