api: libgfapi symbol versions break LTO in Fedora rawhide/f33

[kalebskeithley]

Description of problem:

The way symbol versions are implemented is incompatible with gcc-10 and LTO.

Fedora provenpackager Jeff Law (law [at] redhat.com) writes in the Fedora dist-git glusterfs.spec:
This package uses top level ASM constructs which are incompatible with LTO.
Top level ASMs are often used to implement symbol versioning. gcc-10
introduces a new mechanism for symbol versioning which works with LTO.
Converting packages to use that mechanism instead of toplevel ASMs is
recommended.

At the time that gfapi symbol versions were first implemented we copied the GNU libc (glibc) symbol version implementation following drepper's symbol versioning HOWTO.

Now gcc-10 has a symver attribute that can be used instead.

The exact command to reproduce the issue:

Build glusterfs on Fedora recent fedora rawhide?

The full output of the command that failed:

Expected results:

Additional info:

- The output of the gluster volume info command:

- The operating system / glusterfs version:

[gluster-ant]

A patch https://review.gluster.org/24666 has been posted that references this issue.

api: libgfapi symbol versions break LTO in Fedora rawhide/f33

The way symbol versions are implemented is incompatible with gcc-10 and LTO.

Fedora provenpackager Jeff Law (law [at] redhat.com) writes in the
Fedora dist-git glusterfs.spec:
This package uses top level ASM constructs which are incompatible with LTO.
Top level ASMs are often used to implement symbol versioning. gcc-10
introduces a new mechanism for symbol versioning which works with LTO.
Converting packages to use that mechanism instead of toplevel ASMs is
recommended.

In particular, note that the version of gluster in Fedora rawhide/f33 is
glusterfs-8.0RC0. Once this fix is merged it will be necessary to backport
it to the release-8 branch.

At the time that gfapi symbol versions were first implemented we copied
the GNU libc (glibc) symbol version implementation following Uli Drepper's
symbol versioning HOWTO.

Now gcc-10 has a symver attribute that can be used instead. (Maybe it
has been there all along?)

Both the original implemenation and this implemenation yield the same
symbol versions. This can be seen by running
nm -D --with-symbol-versions libgfapi.so
on the libgfapi.so built before and after applying this fix.

Change-Id: I05fda580afacfff1bfc07be810dd1afc08a92fb8
Fixes: #1352
Signed-off-by: Kaleb S. KEITHLEY kkeithle@redhat.com

[gluster-ant]

A patch https://review.gluster.org/24672 has been posted that references this issue.

api: libgfapi symbol versions break LTO in Fedora rawhide/f33

The way symbol versions are implemented is incompatible with gcc-10 and LTO.

Fedora provenpackager Jeff Law (law [at] redhat.com) writes in the
Fedora dist-git glusterfs.spec:
This package uses top level ASM constructs which are incompatible with LTO.
Top level ASMs are often used to implement symbol versioning. gcc-10
introduces a new mechanism for symbol versioning which works with LTO.
Converting packages to use that mechanism instead of toplevel ASMs is
recommended.

In particular, note that the version of gluster in Fedora rawhide/f33 is
glusterfs-8.0RC0. Once this fix is merged it will be necessary to backport
it to the release-8 branch.

At the time that gfapi symbol versions were first implemented we copied
the GNU libc (glibc) symbol version implementation following Uli Drepper's
symbol versioning HOWTO.

Now gcc-10 has a symver attribute that can be used instead. (Maybe it
has been there all along?)

Both the original implemenation and this implemenation yield the same
symbol versions. This can be seen by running
nm -D --with-symbol-versions libgfapi.so
on the libgfapi.so built before and after applying this fix.

Change-Id: I05fda580afacfff1bfc07be810dd1afc08a92fb8
Fixes: #1352
Signed-off-by: Kaleb S. KEITHLEY kkeithle@redhat.com

[stale]

Thank you for your contributions.
Noticed that this issue is not having any activity in last ~6 months! We are marking this issue as stale because it has not had recent activity.
It will be closed in 2 weeks if no one responds with a comment here.

[stale]

Closing this issue as there was no update since my last update on issue. If this is an issue which is still valid, feel free to open it.