Consider versioning all symbols

[libfuse]

Consider versioning all symbols

[Nikratio]

Thanks for the patch and report! Could you explain what exactly the patch does? What does it mean to add @FUSE_UNVERSIONED to the various symbols (pointers to documentation are also happily accepted)?

[fsvm88]

As far as I understand (I'm not an expert in the area, though I understand some things) the patch versions all the "unversioned" symbols with "FUSE_UNVERSIONED" version.
Then, in the versionscript nothing special is done for those symbols, leaving them the default when no particular version is required.
I understood this is to workaround a bug in the glibc implementation (see all the bugs I linked, I recall it's written somewhere).

I think the closest thing you can call documentation are this bug:

• https://sourceware.org/bugzilla/show_bug.cgi?id=13521

And this post from flameeyes:

• https://blog.flameeyes.eu/2011/06/gold-readiness-obstacle-2-base-versioning

Let me know if I can be of further help.

[Nikratio]

I am tempted to simply version all symbols in the upcoming (backwards incompatible) libfuse3 release and leave this issue unfixed in fuse 2.x. Do you see any problem with that?

[fsvm88]

The only issue I see is with the adoption times of libfuse3.
There are a plethora of fuse-based filesystems that depend on the stable fuse 2.9 API, which has been around for at least 3 years (not counting that probably most of the API didn't change at all throughout 2.x versions, but I didn't check).
Most of these filesystems are distributed by distros, and I guess most of the binary ones are already shipping the patch in some form in order to compile fuse properly if they are using the gold linker. Since libfuse3 would be a backwards incompatible change, it might make sense to merge the patch upstream until libfuse3 gets wider adoption and fuse 2.x gets phased out, it's a little less maintainership for distros in the end. :-)
That said, I'm usually pro API-breaks, because they force people to upgrade and avoid "lets keep version 0.0.1 API around just in case" scenarios.
Your pick. ;-)

[Nikratio]

My only worry is that the patch may have side effects that I don't foresee. But if it's widely used that wouldn't be a concern and I'd be happy to apply it. But what distributions are using the Gold linker? I'm only aware if it being an option for Gentoo and Arch (which doesn't exactly qualify as "widely used").

[fsvm88]

Fedora seems to have a project for it, not sure about the current status (currently it seems not implemented):

• https://fedoraproject.org/wiki/Features/GoldLinkerDefault

This seems to be a Debian project similar to the Fedora one (still, seems unimplemented):

• https://wiki.debian.org/ToolChain/DSOLinking

I couldn't find any other projects for "big" distros.
I'm not pushing on either side, as I don't have knowledge to make an informed decision. Maybe we can leave this open for a while. In the meantime I can ping the bug on the Gentoo bugtracker (as that's my distro of choice) and see what happens.

[Nikratio]

Could you maybe provide a pull request for the master branch?

[Nikratio]

According to https://bugs.gentoo.org/show_bug.cgi?id=402967#c20 this issue has now been fixed in the Gold linker instead - but it may still make sense to version all symbols.

[Nikratio]

I just looked into this, and FUSE 3 already versions all exported symbols.