CyberShadow
Not compiling by default
First of all, thank you for the great tool.
The issue I find myself with is that lately I am not able to compile the tool following the given instructions. The systems tested are:
- Arch
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo
IMAGE_ID=archlinux
IMAGE_VERSION=2025.08.01
- Manjaro
Manjaro Linux
DISTRIB_ID="ManjaroLinux"
DISTRIB_RELEASE="25.0.8"
DISTRIB_CODENAME="Zetar"
DISTRIB_DESCRIPTION="Manjaro Linux"
Manjaro Linux
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/"
BUG_REPORT_URL="https://manjaro.org/help/"
PRIVACY_POLICY_URL="https://manjaro.org/privacy-policy/"
LOGO=manjarolinux
In both scenarios, just executing dub build -b release gets the processor stuck at 100% and it will never finish. For example:
- Arch
[arch@host-mirror btdu]$ /usr/bin/time dub build -b release
Starting Performing "release" build using /usr/bin/dmd for x86_64.
Up-to-date emsi_containers 0.9.0: target for configuration [library] is up to date.
Building btdu 0.6.0+commit.2.gc250916: building configuration [application]
^CCommand terminated by signal 2
0.01user 0.01system 8:25.19elapsed 0%CPU (0avgtext+0avgdata 12844maxresident)k
0inputs+8outputs (0major+2228minor)pagefaults 0swaps
[arch@host-mirror btdu]$
- Manjaro
gugo@boo ~/g/btdu (master) > /usr/bin/time dub build -b release
Starting Performing "release" build using /usr/bin/dmd for x86_64.
Up-to-date emsi_containers 0.9.0: target for configuration [library] is up to date.
Building btdu 0.6.0+commit.2.gc250916: building configuration [application]
^CCommand terminated by signal 2
0.01user 0.01system 4:56.31elapsed 0%CPU (0avgtext+0avgdata 12788maxresident)k
0inputs+48outputs (0major+2258minor)pagefaults 0swaps
gugo@boo ~/g/btdu (master) [SIGINT]>
But in the same scenario I found out (by looking at other issues) that the compiler may be changed, and using ldc (dub build --compiler=ldc2 -b release) does not produce the same behavior of never finishing compilation:
- Arch
[arch@host-mirror btdu]$ /usr/bin/time dub build --compiler=ldc2 -b release
Starting Performing "release" build using ldc2 for x86_64.
Up-to-date emsi_containers 0.9.0: target for configuration [library] is up to date.
Building btdu 0.6.0+commit.2.gc250916: building configuration [application]
source/btdu/ui/deletion.d(218,27): Deprecation: function `core.sync.event.Event.set` is deprecated - Use setIfInitialized() instead
this.subvolumeResume.set();
^
../../.dub/packages/ae/0.0.3461/ae/sys/file.d(2614,4): Deprecation: cannot initialize field `data` with itself
this.data = data;
^
Linking btdu
Finished To force a rebuild of up-to-date targets, run again with --force
55.78user 1.64system 0:57.85elapsed 99%CPU (0avgtext+0avgdata 2690444maxresident)k
26936inputs+42832outputs (11major+639668minor)pagefaults 0swaps
[arch@host-mirror btdu]$
- Manjaro
gugo@boo ~/g/btdu (master)> /usr/bin/time dub build --compiler=ldc2 -b release
Starting Performing "release" build using ldc2 for x86_64.
Up-to-date emsi_containers 0.9.0: target for configuration [library] is up to date.
Building btdu 0.6.0+commit.2.gc250916: building configuration [application]
source/btdu/ui/deletion.d(218,27): Deprecation: function `core.sync.event.Event.set` is deprecated - Use setIfInitialized() instead
this.subvolumeResume.set();
^
../../.dub/packages/ae/0.0.3461/ae/sys/file.d(2614,4): Deprecation: cannot initialize field `data` with itself
this.data = data;
^
Linking btdu
Finished To force a rebuild of up-to-date targets, run again with --force
57.12user 1.57system 0:58.79elapsed 99%CPU (0avgtext+0avgdata 2691748maxresident)k
4008inputs+43008outputs (5major+598923minor)pagefaults 0swaps
gugo@boo ~/g/btdu (master)>
Meanwhile the expected behavior is found in a debian installation:
- /etc/*release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.0
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
- Compilation log
debian@host-wrk:~/btdu$ /usr/bin/time dub build -b release
Starting Performing "release" build using /usr/bin/ldc2 for x86_64.
Up-to-date emsi_containers 0.9.0: target for configuration [library] is up to date.
Building btdu 0.6.0+commit.2.gc250916: building configuration [application]
source/btdu/ui/deletion.d(218,27): Deprecation: function `core.sync.event.Event.set` is deprecated - Use setIfInitialized() i
nstead
Linking btdu
Finished To force a rebuild of up-to-date targets, run again with --force
59.79user 1.88system 1:02.36elapsed 98%CPU (0avgtext+0avgdata 2982124maxresident)k
2056inputs+44256outputs (2major+686863minor)pagefaults 0swaps
debian@host-wrk:~/btdu$
In regards to Arch and Manjaro, the same behavior is seen if using the AUR and compiling with PKGBUILD system, that being of the compilation never finishing.
I am not an expert in D, but this is quite an interesting behavior, that maybe someone else may have encountered.
Thank you and kind regards,
Gugo
Hi, it's possible that the compilation is hitting an inefficient code path in the DMD compiler. However, I think the compilation time should still be finite.
Can I ask how long have you tried waiting for compilation to complete, and if you were seeing memory usage hit the machine's available memory capacity (thus causing swapping)?
Hello! The longest I waited was about 1 hour, my system was not even at 50% ram utilization, and DMD was about 2GB of memory usage (not fluctuating), btop was not showing any significant usage of anything but the CPU (not waiting on disk, not waiting on network).
Thanks! Could you share the DMD version this was with? You can get it with dmd --version or e.g. pacman -Q dmd.
Sure, now I also see that the problem may be the same one due to them using the same version
- Arch
[arch@host-mirror ~]$ dmd --version
DMD64 D Compiler v2.111.0
Copyright (C) 1999-2025 by The D Language Foundation, All Rights Reserved written by Walter Bright
[arch@host-mirror ~]$ pacman -Q dmd
dmd 1:2.111.0-1
[arch@host-mirror ~]$
- Manjaro
gugo@boo ~/g/btdu (master)> dmd --version
DMD64 D Compiler v2.111.0
Copyright (C) 1999-2025 by The D Language Foundation, All Rights Reserved written by Walter Bright
gugo@boo ~/g/btdu (master)> pacman -Q dmd
dmd 1:2.111.0-1
gugo@boo ~/g/btdu (master)>
I am having the same issue on openSUSE Tumbleweed with dmd 2.111.0 . On openSUSE Leap 16.0 with dmd 2.109.1 it successfully builds.
I can reproduce the problem with DMD 2.111.0. However, the problem does not occur with 2.110.0 or current master. So, you can:
- downgrade your D compiler to 2.110.0
- build a D compiler from the latest Git version
- wait until 2.112.0 is released
Yes, the issue is with the current DMD. I had it too.
btdu builds successfully with either GDC or LDC. If I remember well, both are available on ArchLinux, and should be used instead of DMD, especially for release builds. Yesterday I've built Fedora btdu RPMs using both, so I see no reason why it should not work on ArchLinux.
I suppose you want to use DMD for CI, right? Makes sense, in which case the best option is to pin DMD to 2.110.0 until 2.112.0 is released.
There is now a Nix flake in master, which is verified to build in CI. This is now the recommended way to build and run btdu, as it ensures all dependencies are at tested versions - other distros' compilers remain supported on a best-effort basis.
Let me know if you feel there's anything else to be done here; closing for now.