Re: errors compiling bcachefs-tools v1.20.0 on debian 12

["John Stoffel" <john@stoffel.org>]

>>>>> "Krzysztof" == Krzysztof Hajdamowicz <krzysztof@hajdamowicz.info> writes:

> W dniu 19.03.2025 o 15:16, John Stoffel pisze:
>>>>>>> "Malte" == Malte Schröder <malte.schroeder@tnxip.de> writes:
>>> On 18/03/2025 22:04, John Stoffel wrote:
>>>>>>>>> "Malte" == Malte Schröder <malte.schroeder@tnxip.de> writes:
>>>>> Libs in Debian 12/Bookworm are too old for bcachefs-tools. I think
>>>>> someone pulled it of by forcing some libs from Trixie, but that caused
>>>>> other things to break.

> I am one of the people that butchered bcachefs-tools to work on my 
> Bookworm/Proxmox 8 machine.

> The recent version of bcachefs-tools require liburcu in version 0.14 and 
> higher.
> Debian Bookworm uses 0.13, while Debian Trixie has 0.14.

> I asked debian-backports team if they could backport it [1].  In
> response, I was informed that newer package uses 64bit time_t; This
> makes it incompatible with Bookworm and a patch would be needed to
> address that.

I was able to self-compile liburcu without any problems and I've got
bcachefs-tools working on Debian 12.  So I think the solution might be
to just make liburcu a sub-project for bcachefs-tools if the system
provided library isn't new enough.  

> As my risk factor for this machine is higher than usual, I've created a 
> setup with:

>   * LXC container initially set up with Bookworm, containing all build
>     dependencies.
>   * I recompiled liburcu8t64 from Trixie to Bookworm
>   * The package was then force-installed - rendering dpkg package
>     database with conflicting dependencies.
>     apt-cache rdepends shows that xfs and glusterfs depends on working
>     liburcu.
>     Since I do not use either of them, this is something I can live with.

I just installed liburcu into /usr/local/lib and setup my
LD_LIBRARY_PATH to include it as a quick hack.  I really need to try
and tweak the bcachefs-tools Makefile to hardcode that path into the
binary. 

>   * Then I built bcachefs-tools
>   * The resulting bcachefs binary and liburcu8t64 packages were copied
>     to the target system.
>   * Finally, I force-installed them, leaving the dpkg database with
>     broken dependencies.

> 1: https://lists.debian.org/debian-backports/2025/01/msg00003.html
>>>> So what is the best Linux distro to use to compile bcachefs-tools?

> There is none until you transfer compiled binary with its dependencies.
> # ldd bcachefs-tools/bcachefs
>      linux-vdso.so.1 (0x0000749f55207000)
>      liburcu.so.8 => /lib/x86_64-linux-gnu/liburcu.so.8 (0x0000749f54db5000)
>      libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 
> (0x0000749f54d5e000)
>      libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x0000749f54d54000)
>      libsodium.so.23 => /lib/x86_64-linux-gnu/libsodium.so.23 
> (0x0000749f54cfa000)
>      libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x0000749f54cdb000)
>      liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x0000749f54cb3000)
>      libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x0000749f54bf7000)
>      libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x0000749f54bc9000)
>      libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 
> (0x0000749f54bc2000)
>      libaio.so.1 => /lib/x86_64-linux-gnu/libaio.so.1 (0x0000749f54bbd000)
>      libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
> (0x0000749f54b9d000)
>      libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000749f549ba000)
>      /lib64/ld-linux-x86-64.so.2 (0x0000749f55209000)
>      libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x0000749f549b5000)

>>> I'd recommend you join #bcache at OFTC. This kind of things has been
>>> and still is discussed there and people have found solutions that
>>> worked for them regarding -tools vs Bookworm. My personal "solution"
>>> was to upgrade to Trixie.
>> Is there a base OS (Fedora?) that people use for development

> As far as I know, most of bcachefs development happens on Nix.
>> which I can use to cross build a package for Debian?
> I would suggest upgrading to Trixie. I can't as Proxmox is not 
> compatible with Trixie yet.