target libfuse version 30

[neheb]

libfuse only defines fuse_new_30 when FUSE_USE_VERSION == 30. It does not
define fuse_new_31 in the headers.

fuse_new_31 and _32 seem to be internal only.

Fixes a linking issue:
ld: sshfs.p/sshfs.c.o: in function main': sshfs.c:(.text.startup+0x506): undefined reference to fuse_new'
ld: sshfs.c:(.text.startup+0x506): undefined reference to `fuse_new'

[Nikratio]

Sorry, I do not understand (and I can't reproduce the problem). SSHFS uses fuse_new, not fuse_new_{30,31,32}. Could you help me understand the issue and the fix?

[neheb]

https://github.com/libfuse/libfuse/blob/master/include/fuse.h#L922

[yann-morin-1998]

Sorry, I do not understand (and I can't reproduce the problem). SSHFS uses fuse_new, not fuse_new_{30,31,32}. Could you help me understand the issue and the fix?

libfuse 3.10 does not have a fuse_new symbol:

$ readelf -W -a libfuse3.so.3.10.0 |grep fuse_new
    16: 00010fd8   256 FUNC    GLOBAL DEFAULT   11 fuse_new_30@@FUSE_3.1
   460: 0001094c  1676 FUNC    LOCAL  DEFAULT   11 fuse_new_31
   580: 00010fd8   256 FUNC    GLOBAL DEFAULT   11 fuse_new_30

[yann-morin-1998]

Sorry, I do not understand (and I can't reproduce the problem). SSHFS uses fuse_new, not fuse_new_{30,31,32}. Could you help me understand the issue and the fix?

libfuse 3.10 does not have a fuse_new symbol:

So I did some more testing, and the above is true with a uClibc-based toolchain, while with glibc, we have:

    71: 0000d624   180 FUNC    GLOBAL DEFAULT   12 fuse_new_30@@FUSE_3.1
   148: 0000d624   180 FUNC    GLOBAL DEFAULT   12 fuse_new@FUSE_3.0
   230: 0000d0f8  1324 FUNC    GLOBAL DEFAULT   12 fuse_new@@FUSE_3.1
   804: 0000d0f8  1324 FUNC    LOCAL  DEFAULT   12 fuse_new_31
   911: 0000d624   180 FUNC    GLOBAL DEFAULT   12 fuse_new_30
   988: 0000d624   180 FUNC    GLOBAL DEFAULT   12 fuse_new@FUSE_3.0
  1070: 0000d0f8  1324 FUNC    GLOBAL DEFAULT   12 fuse_new@@FUSE_3.1

So in this case, fuse_new exists, but is a versioned symbol. And we're reaching the limits of my knowledge there...

[yann-morin-1998]

Sorry, I do not understand (and I can't reproduce the problem). SSHFS uses fuse_new, not fuse_new_{30,31,32}. Could you help me understand the issue and the fix?

libfuse 3.10 does not have a fuse_new symbol:

So I did some more testing, and the above is true with a uClibc-based toolchain

To provide one more data point, with a musl-based toolchain, the situation is like with glibc.

So, the issue occurs only with a uClibc-based toolchain.

Not sure what else I can provide to help fix this... Just ask if you need further info or testsing.

[neheb]

All I know is, this patch fixes it.

[yann-morin-1998]

All I know is, this patch fixes it.

That a patch fixes an issue is not what a maintainer wants to know.

What they want to know, are the conditions why the issue occurs, so that they can assess if the patch is indeed the proper fix, or is just a workaround. As maintainers, they have a much better grasp at the code, its design and layout and intricate interdependencies, to review a patch, and if needed, suggest a better fix.

Additionally, knowing those conditions will allow them to actually test and validate the patch.

Finally, as maintainers, they will have to carry and care about that change in the future, and ensure that it does not break back. If a patch does not explain in details why it was done, chances are high it gets reverted sooner or later if the issue it purportedly fixed can't be reproduced.

[neheb]

~/d/openwrt > strings ~/devstuff/openwrt/staging_dir/target-powerpc_8540_musl/usr/lib/libfuse3.so | grep fuse_new
fuse_new_30
fuse_new
fuse_new_31
fuse_new@@FUSE_3.1
fuse_new@FUSE_3.0
fuse_new_30
~/d/openwrt > strings ~/devstuff/openwrt/staging_dir/target-arc_archs_uClibc/usr/lib/libfuse3.so | grep fuse_new
fuse_new_30
fuse_new_31
fuse_new_30

Hmm...

[neheb]

Found the issue: https://github.com/libfuse/libfuse/blob/master/lib/fuse_misc.h#L16

These hacks need to go the way of the dodo.

[neheb]

Closing this as lobfuse was fixed. Strictly speaking, it's still a problem with macOS but I don't know if aahfs even works there.

[yann-morin-1998]

@neheb Thank you for the further investigations, and eventual proper fix. :-)

We'll now be able to also fix that in Buildroot, so extra thanks are due, too.