https://issues.dlang.org/show_bug.cgi?id=17838
Issue ID: 17838 Summary: rdmd file-descriptor issues with snap packages Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: tools Assignee: nob...@puremagic.com Reporter: joseph.wakel...@webdrake.net rdmd uses spawnProcess to launch the D compiler of choice, and passes a custom `File` instance to the `stdout` parameter. This means that the D compiler has to inherit a file-descriptor from rdmd. For traditional Linux packages, this is not a problem. However, where snap packages are concerned, this creates an issue: when the D compiler is itself a snap package, its confinement rules prevent it from inheriting the file descriptor, and rdmd will exit with an error message: ``` $ rdmd --compiler=ldc2 hello.d Failed to flush stdout: Permission denied Failed: ["ldc2", "-v", "-o-", "hello.d", "-I."] ``` Some extended discussion of this issue can be found in this thread on the snapcraft forums: https://forum.snapcraft.io/t/failed-to-flush-stdout-permission-denied/485 This is considered at least partly a bug in snapd, hence I've held off on reporting it as an rdmd issue, but it looks like this is going to be long-lived enough for me to think it might be worth addressing in rdmd itself if possible. A recent patch to rdmd (https://github.com/dlang/tools/commit/f7e6f4ed925f6a8f97b4c0f02cfce2620489357a) partially addresses this issue, as it ensures that when rdmd is invoking a D compiler within the same snap package as itself, the confinement rules do not come into play (because the compiler executable is launched directly, instead of indirectly via the wrapper script that the snap package exposes to the host system). However, this still leaves unaddressed the broader issue of rdmd invoking a compiler provided by a separate snap package (e.g. the ldc2 snap package). So: can rdmd be either patched or invoked in order to avoid the D compiler it invokes needing to inherit a file descriptor from it? :-) --