bacula1[13]-client: build without sbrk

[brooks]

Summary

Avoid the deprecated sbrk interface and simply report no heap usage.
Heap usage as reported by sbrk() is often inaccurate and this
allows the code to build for targets without sbrk support.

[brooks]

Compiled, but untested on an amd64 system without sbrk.

Upstream might want to take a different tact here, but this was easy.

I've not patched bacula9 because I understand it's going away and this code is duplicated rather than in a library there.

[dvl]

In D42979#979906, @brooks wrote:

Compiled, but untested on an amd64 system without sbrk.

How can I tell if I have sbrk?

[16:12 r730-01 dvl ~] % grep -i sbrk /var/run/dmesg.boot 
[16:17 r730-01 dvl ~] %

Upstream might want to take a different tact here, but this was easy.

I will suggest this to them, but I suspect it would only be applied to version 15, about to be released. re https://git.langille.org/dvl/ports/src/branch/master/sysutils

I've not patched bacula9 because I understand it's going away and this code is duplicated rather than in a library there.

I plan to deprecated bacula9 and bacula11 with a 3 month expiration date shortly after we get bacula15 into the tree. I figure we should deprecate bacula13 about three months after that.

[brooks]

In D42979#980092, @dvl wrote:

In D42979#979906, @brooks wrote:

Compiled, but untested on an amd64 system without sbrk.

How can I tell if I have sbrk?

[16:12 r730-01 dvl ~] % grep -i sbrk /var/run/dmesg.boot 
[16:17 r730-01 dvl ~] %

You do unless you're on aarch64 and riscv. It's part of libc since forever (and also considered deprecated since the 90's). I'm trying to remove it which means I'm cleaning up ports that are broken by its absence.

Upstream might want to take a different tact here, but this was easy.

I will suggest this to them, but I suspect it would only be applied to version 15, about to be released. re https://git.langille.org/dvl/ports/src/branch/master/sysutils

Feel free to CC me. I'm happy to engage here and discuss options. This patch it mostly aimed to be good enough to let us build bacula for aarch64 and riscv.

I've not patched bacula9 because I understand it's going away and this code is duplicated rather than in a library there.

I plan to deprecated bacula9 and bacula11 with a 3 month expiration date shortly after we get bacula15 into the tree. I figure we should deprecate bacula13 about three months after that.

Sounds good to me.

[brooks]

In D42979#980388, @brooks wrote:

In D42979#980092, @dvl wrote:

In D42979#979906, @brooks wrote:

Compiled, but untested on an amd64 system without sbrk.

How can I tell if I have sbrk?

[16:12 r730-01 dvl ~] % grep -i sbrk /var/run/dmesg.boot 
[16:17 r730-01 dvl ~] %

You do unless you're on aarch64 and riscv. It's part of libc since forever (and also considered deprecated since the 90's). I'm trying to remove it which means I'm cleaning up ports that are broken by its absence.

FWIW, D42862 is a review to remove sbrk support.

[divisible_abdominal010_orias.one]

I just wanted to add a note that I've been using the patches listed here with bacula15 on aarch64 for ~a month. The patch sysutils/bacula13-server/files/patch-src_lib_bsys.c applies cleanly to bacula15-server as well, and bacula-fd on ARM seems to be doing its job perfectly. I've been running this on a bunch raspberry pi 3 and 4s and both the backup and restore functionality works as intended. Unfortunately, I don't have any risc-v boards to validate that part, so I can only add a "works for me" on aarch64.

Is there something that I could add here to help testing and get this merged? If necessary I can provide (build or application) logs or I could try testing a specific scenario/configuration if you have something specific in mind.

[dvl]

See https://cgit.freebsd.org/ports/commit/?id=9df94c4d9d1c50f758e9be67e51060a14527e2cc

[dvl]

Thank you for your help. :)