Build failure on arm{el,hf}: Incompatible pointer types in `ch_fuse.c`

[wiene]

Charliecloud 0.37 fails to build from source with the following error message on armel and armhf:

ch_fuse.c:68:19: error: initialization of ‘void (*)(struct fuse_req *, fuse_ino_t,  uint64_t)’ {aka ‘void (*)(struct fuse_req *, long long unsigned int,  long long unsigned int)’} from incompatible pointer type ‘void (*)(struct fuse_req *, fuse_ino_t,  long unsigned int)’ {aka ‘void (*)(struct fuse_req *, long long unsigned int,  long unsigned int)’} [-Werror=incompatible-pointer-types]
   68 |     .forget     = &sqfs_ll_op_forget,
      |                   ^
ch_fuse.c:68:19: note: (near initialization for ‘OPS.forget’)

Full build logs are available here:

• armel
• armhf

The corresponding bug in the Debian bug tracker is bug#1065793.

[olifre]

I think the situation is as follows:

• The badly named config.h from SquashFUSE is skipped in Charliecloud, see https://github.com/hpc/charliecloud/blob/c2bcd802a43f9618ff14db4a0567a3ec9e3df558/bin/ch_fuse.c#L17-L22
• fuse_lowlevel.h uses uint64_t usually as third argument for forget: https://github.com/libfuse/libfuse/blob/a6a219f5344a5c09cec34416818342ac220a0df2/include/fuse_lowlevel.h#L282
• However, SquashFUSE only uses uint64_t if HAVE_FUSE_LL_FORGET_OP_64T was set: https://github.com/vasi/squashfuse/blob/94f998c58d2bb6dff00173f33140a0354adce324/ll.h#L111-L117
• This usually comes in via config.h.
• We enter the wrong branch here which works on non-armel and non-armhf systems "by accident" due to the size of long unsized int on those systems.

In theory, HAVE_FUSE_LL_FORGET_OP_64T has to be defined depending on the FUSE version SquashFUSE was built against. However, it seems FUSE switched to uint64_t 11 years ago already: https://github.com/libfuse/libfuse/commit/46f1ac6c1a280706aa290bcc60349eb5f843cf17 So maybe it can be set unconditionally?

[reidpr]

I don't 100% follow, and I don't have access to armel or armhf machiens, but here are some ideas.

1. I’m happy with additional kludges to make build work on these architectures. If one of you (or anyone) would like to submit a PR, I’d be extremely grateful.

2. I do see a recent commit on SquashFUSE that involves HAVE_FUSE_LL_FORGET_OP_64T and mentions 32-bit builds: vasi/squashfuse@cb148fc.

[olifre]

After reading through more code, I think the gist is:

• FUSE 2 implements the forget operation with unsigned long nlookup as third parameter.
• FUSE 3 implements the forget operation with uint64_t nlookup as third parameter.

This difference does not matter on non-32 bit systems, since both types have the same size. Squashfuse broke on 32 bit systems (until the commit you linked) since it used unsigned long no matter which FUSE version it was built against.

I think we have two possible approaches to solve this:

1. We could hardcode #define HAVE_FUSE_LL_FORGET_OP_64T in ch_fuse.c, before including <squashfuse/ll.h>. This is compatible with any architecture as long as libfuse version >=3 is used, as this uses uint64_t in all versions (see https://github.com/libfuse/libfuse/commit/46f1ac6c1a280706aa290bcc60349eb5f843cf17 ). However, it is incompatible with libfuse version 2.
2. We could replicate a check similar to what squashfuse is doing.

I have never actually tested whether Charliecloud with squashfuse built against libfuse version 2 would work (and dependencies state libfuse3 is required), so I would propose to go for variant 1, as it seems more maintainable.

Sadly, I also don't have access to an armhf or armel system, but I could create a PR later today and maybe @wiene can test it via the Debian infrastructure — (untested) PR coming up, I'll leave it in draft mode until @wiene (or someone with the actual hardware) can confirm it works as expected.