Fix building with various distributions' compilers / ncurses versions

[pallaswept]

Hi, congrats on the new release!

I wanted to give this a try out but when I ran the pre-built binary from the releases page, I got:

Fatal error: Could not create the ncurses screen object. Are terminfo files installed for your terminal? Perhaps try running with "TERM=xterm".

I figured this must be some dependency problem, so I tried to get it to build locally (in an RPM package for opensuse, which was a challenge unto itself!). The build seems to work, but now when I run btdu, I just see a W in the top left corner, and nothing happens.

Thanks for any advice you might offer. Happy new year :)

[CyberShadow]

Hi, can you share more information about your system?

• What software distribution and version are you using?
• What terminal emulator? What does env | grep TERM print?
• Have you tried building from source with Nix?

[pallaswept]

Sure, I'm on openSUSE Tumbleweed 20251231, I'm using Konsole, and it tells me:

> env | grep TERM
COLORTERM=truecolor
TERM=xterm-256color

I haven't tried building with nix, I built it locally in an RPM packaging VM. The package was based on this one for 0.6.0 but with updated sources.

I also tried to replicate the AUR pkgbuild in that RPM, but had the same result.

[CyberShadow]

Thanks! Released 0.7.1 which should fix this.

https://github.com/CyberShadow/btdu/releases/tag/v0.7.1

[pallaswept]

This has the pre-build version working, thank you!
Building from source still just gave me a W in the top left and that's all. I've zero experience with dlang or nix. so when copying the existing packages didn't work, I was already out of ideas :D

[CyberShadow]

Can you post the full definition of the package you're building from source? I'll need to be able to reproduce it to debug it.

(I'm 90% certain the problem is with the package or environment rather than the btdu code, e.g. a version mismatch...)

[pallaswept]

Sure! Here's the spec file as it stands right now. It's basically a clone of the AUR package, with the reentrant ncurses flag from the existing 0.6.0 package (it wouldn't build without that flag)

%define ae_ver 0.0.3701
%define btrfs_ver 0.0.21
%define ncurses_ver 1.0.0
%define containers_ver 0.9.0

Name:           btdu
Version:        0.7.1
Release:        0
Summary:        Sampling disk usage profiler for btrfs
License:        GPL-2.0
URL:            https://github.com/CyberShadow/btdu
Source:         https://github.com/CyberShadow/btdu/archive/refs/tags/v%{version}.tar.gz#/%{name}-%{version}.tar.gz
# Dependencies
Source1:        https://github.com/CyberShadow/ae/archive/v%{ae_ver}.tar.gz
Source2:        https://github.com/CyberShadow/d-btrfs/archive/v%{btrfs_ver}.tar.gz
Source3:        https://github.com/D-Programming-Deimos/ncurses/archive/v%{ncurses_ver}.tar.gz
Source4:        https://github.com/dlang-community/containers/archive/v%{containers_ver}.tar.gz

BuildRequires:  dmd
BuildRequires:  dub
BuildRequires:  ldc
BuildRequires:  ldc-phobos-devel
BuildRequires:  phobos-devel-static
BuildRequires:  pkgconfig(ncursesw)
BuildRequires:  pkgconfig(zlib)

%description
Sampling disk usage profiler for btrfs

%prep
%setup -q -a 4 -a 3 -a 2 -a 1

%build
ln -s ./ae-%{ae_ver} ae
dub add-local ./ae %{ae_ver}
dub add-local ./d-btrfs-%{btrfs_ver} %{btrfs_ver}
dub add-local ./ncurses-%{ncurses_ver} %{ncurses_ver}
dub add-local ./containers-%{containers_ver} %{containers_ver}

export DFLAGS="-d-version=NCURSES_REENTRANT"
dub --skip-registry=all build --compiler=ldc2 -b release --rdmd

%install
install -m0755 -D %{name} %{buildroot}%{_bindir}/%{name}
install -m0644 -D %{name}.1 %{buildroot}%{_mandir}/man1/%{name}.1

%check

%files
%license COPYING
%doc README.md
%{_bindir}/%{name}
%{_mandir}/man1/%{name}.1%{?ext_man}

%changelog

[CyberShadow]

Thanks, could you please try building from the next branch (or applying the patches here)?

[pallaswept]

Thanks mate. Gave that one a try but it was a bit unhappy. I guess the distro's ncurses are a bit different?

[   42s]     Building btdu ~master: building configuration [application]
[   43s] /usr/lib64/gcc/x86_64-suse-linux/15/include/stddef.h(465,18): Error: undefined identifier `nullptr`, did you mean alias `nullptr_t`?
[   43s] /usr/include/ncurses.h(643,36): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(647,35): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(679,30): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(680,26): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(681,26): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(683,35): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(684,34): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(685,37): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(699,37): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(700,28): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(701,42): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(702,37): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(704,34): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(706,35): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(708,32): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(767,35): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(772,37): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(798,36): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] /usr/include/ncurses.h(824,35): Error: undefined identifier `bool`, did you mean function `box`?
[   43s] Error ldc2 failed with exit code 1.

[CyberShadow]

Well, there's good news and bad news:

• The good news is that I managed to reproduce the problem, understand the root cause, and create a working patch that fixes building on OpenSuSE and possibly more distributions in a cross platform way.

• The bad news is that this patch is super-ugly and requires a very recent version of the compiler - more recent than what most distributions carry anyway.

• But, the other good news is that things are improving. I've also put together a few patches to send upstream which fix the ugliness in the correct place.

Once the patches land in the compiler and build tool, bubble through their releases, and get included in software distributions, we should one day be able to build D programs which gracefully and correctly integrate with system C libraries on any POSIX distribution. However, unfortunately that day is not today. So, for building from source, I can realistically only support the Nix-based regular builds and the Nix-based reproducible static builds, for which support is guaranteed by virtue of Nix's determinism.

Can I ask if there was any particular reason you wanted to pursue a distribution-packaging-centric approach to building btdu from source? In practice, I think the only reason why that would be preferable is to conserve disk space (i.e. avoid downloading the Nix userspace) or prepare a package for submitting as an official package.

[pallaswept]

Oh wow I kicked over a hornet's nest, sorry about that!

Can I ask if there was any particular reason you wanted to pursue a distribution-packaging-centric approach to building btdu from source?

Sure! Basically it's nerd PTSD :D I found over the years that the best way to ensure something weird going wrong with my system, regardless of distro, was to diverge from the distro's package management system, building software from source being the number 1 offender.

These days, I don't build anything locally, rather, I build it as an RPM, which happens in a VM, totally isolated from the machine that I'm using (and the network), so the development process can't hurt the production systems, then install the package so its files are tracked by package management, and as a bonus, I can submit the package upstream when I'm done, so everyone on the distro gains the same benefit of reliability from using managed software.

Honestly that's not such a big deal for this tool specifically, so I'm not bothered. btdu is critical to me because of btrfs's bug with quotas causing kernel freezes when snapshots are cleaned up, which means you can't use quotas if you want snapshots, which means you can't check disk usage without btdu... but that's not a job I need to do very often, so using the static pre-build you provide is perfectly acceptable for me (it's not like it leaves config files or libraries or whatever around the drive that might break stuff, it's a single file!).

I just thought that since snapshots on btrfs is a core feature of all the suse distros, which is broken, and btdu is the only workaround, btdu would be a very nice tool to have a native package for it, and spreading btdu around would be a nice way for me to 'give something back' to you for providing us with such a useful tool. So much for that idea, I just made things harder. Sorry!

I'm cool to close this issue now, but I'll leave that to you in case you'd like it open to track those upstream changes. Thanks so much for your help!

[CyberShadow]

Oh wow I kicked over a hornet's nest, sorry about that!

No, no - thank you for filing this, and your aid in helping me understand it! You've made me aware that my understanding of how libraries such as ncurses interact on various distros was a little naive, but the resulting fixes will benefit the entire D ecosystem and hopefully other similar projects in the future. This report was very welcome!

Sure! Basically it's nerd PTSD :D I found over the years that the best way to ensure something weird going wrong with my system, regardless of distro, was to diverge from the distro's package management system, building software from source being the number 1 offender.

Thanks for that context - makes perfect sense to me!

I completely relate to this approach. When I was on Arch Linux, I followed the same discipline: any software that needed to be installed system-wide would get a PKGBUILD and would be built in a chroot (which Arch's tools thankfully automate).

On a tangential note: I don't know if you've looked into Nix or if it fits your workflow, but it might align with your goals here - Nix keeps all its files in /nix/store, completely isolated from the rest of the system, so Nix packages don't interfere with system packages or vice-versa. Just mentioning it as something that might interest you - though as you say, the static binary works perfectly well for this use case!

I'm cool to close this issue now, but I'll leave that to you in case you'd like it open to track those upstream changes.

Yes, let's keep it open as a reminder to occasionally revisit the situation and enable building btdu with distro native tools. I'll change the title to match.