dpboxもtntも、一旦白紙（なるべく手を入れない状態かつ32bit環境での動作）からやり直した方が良いのかもって気がしてきました…
time_tが32bit、本当にここが一番厄介な気がします。Slackware(i686)に限らず、Debian/i386も「過去のx86バイナリとの互換性を保つため32bit time_tのままとする」決定をしているようで。きちんと手間をかければ直せるのでしょうが（64bit OSなら自動的にtime_tは64bitになりますし、32bit OSでも-DTIME_BITS=64で64bit化しますけどね）、単なる表示だけの問題ではなくtime_tを含んだ構造体をディスク上に保存しているとなると…既に保存されているデータとの互換性を一体どうするのかという問題も首をもたげてきます。単に64bit化すりゃいーじゃんという話ではないです、決して。
また、構造体である以上paddingの問題もあります。__attribute__((packed))等で押し込もうものなら、x86系以外の機種ではunaligned-accessによるSIGBUS等に悩まされることになるでしょう。この辺りの問題をよーーっく考えて手を付けないとダメな気がします←と書いている時点で、何も考えずにやっていることがバレバレです:-p
対処については、組込み機器開発における2038年問題への対応事例（デジタルプラクティス Vol.10 No.3 (July 2019)）のようなラッパー関数を使用して32bit time_tを維持する方法や、ディスク上に記録するエントリのみ32bit形式とし（1970/Jan/01 00:00:00〜2004/Jan/10 13:37:03に対応する0x00000000〜0x3fffffffを2038/Jan/19 03:14:08〜に割り当てる）それ以外は全て64bit time_tで処理する方法もありそうです。どのような方法が使えるかはdpboxを動かせれば分かりそうですが、まだ動かせていないので全く見当がつきません。
netbsd-tntのビルドについては、pkgsrc(NetBSD)版はnbmakeを使っているらしいと聞いています。自分はOpenBSDの民なので、CMakeLists.txtを作ってCMakeでのビルドを行えるようにしてしまいました。CMakeによるconfigureによるconfig.h生成の真似事、意外とできてしまうものなのですね…非常に面倒ですが。56.3kg(22:05)