| Summary: | sys-fs/xfsprogs-5.4.0-r1 - ld: init.o (symbol from plugin): in function `progname': (.text+0x0): multiple definition of `progname'; xfs_mdrestore.o (symbol from plugin):(.text+0x0): first defined here | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | ernsteiswuerfel <erhard_f> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | kfm |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=762961 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 705764, 762907 | ||
| Attachments: |
build.log
emerge --info |
||
Created attachment 658972 [details]
emerge --info
This package is an interesting case because it is in everyone's best interests to use the latest version of xfsprogs for maintenance and repair, no matter which kernel they use. The potential snag is that using mkfs.xfs from a release newer than the targeted kernel may or may not produce a filesystem that can be used by said kernel. I decided to investigate this in more detail. Currently, 5.4.0-r1 carries stable keywords for most arches. It follows that we should not expect mkfs.xfs 5.4.0 to generate a filesystem that is guaranteed to be mountable by kernels older than 5.4, even though it might. For newly created filesystems in 2021, 5.4 seems like a reasonable low bar; not least, because it is the penultimate longterm branch. With that in mind, I asked the XFS developers whether mkfs.xfs 5.10.0 was capable of producing a filesystem that could not be mounted by a kernel as old as 5.4, provided that no special options are given. Eric Sandeen kindly responded and indicated that it could not. Specifically, he said: "The only changes since 5.4.0 (git log -p v5.4.0.. libxfs/xfs_format.h | grep "define XFS_SB_FEAT") are BIGTIME and INOBTCNT - neither of which are default in mkfs.xfs." Therefore, it seems to me that it would be worth considering version 5.10.0 for stabilisation. Note, also, that the issue with -fno-common was rectified by the release of 5.5, per the following commit. https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?id=123b851389ef9a012a469ef982ac7b819db59342 *** This bug has been marked as a duplicate of bug 705904 *** Why has this been marked as a duplicate of a bug which is RESOLVED/OBSOLETE, while absolutely nothing has been done to rectify the issue at hand? Eventually, there will be a move to render gcc:10 stable, at which point this issue will simply present itself again. I find it to be discourteous, given that I have made an effort to research the options and present them here. To recap, the choices are to either stabilise a newer version or backport the referenced patch to 5.4.0. The issue is not resolved until such time as one of these options is selected and acted upon. xfsprogs-5.10.0 is being stabilized in bug 762961. (In reply to Mike Gilbert from comment #5) > xfsprogs-5.10.0 is being stabilized in bug 762961. Thank you, Mike. I apologise if the tone of the previous comment came off as being irritable, but a note to that effect wouldn't have hurt. In any case, I think it's a wise decision and I am happy to hear of it. |
Created attachment 658970 [details] build.log xfsprogs-5.4.0-r1 builds fine with gcc-9.3.0-r1 but fails with gcc-10.2.0-r1. [...] /bin/sh ../libtool --quiet --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -o xfs_rtcp -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -flto -ffat-lto-objects -Wl,-O1 -Wl,--as-needed -flto -ffat-lto-objects -Wl,-O1 -Wl,--as-needed -flto -ffat-lto-objects -static xfs_rtcp.o ../libfrog/libfrog.la /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: init.o (symbol from plugin): in function `progname': (.text+0x0): multiple definition of `progname'; xfs_mdrestore.o (symbol from plugin):(.text+0x0): first defined here [LD] libxcmd.la /bin/sh ../libtool --quiet --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -flto -ffat-lto-objects -rpath /lib64 -version-info 0:0:0 -o libxcmd.la command.lo input.lo help.lo quit.lo -lreadline [LD] libhandle.la /bin/sh ../libtool --quiet --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -flto -ffat-lto-objects -rpath /lib64 -version-info 1:3:0 -Wl,--version-script,libhandle.sym -o libhandle.la handle.lo jdm.lo collect2: error: ld returned 1 exit status gmake[2]: *** [../include/buildrules:65: xfs_mdrestore] Error 1 gmake[1]: *** [include/buildrules:35: mdrestore] Error 2 gmake[1]: *** Waiting for unfinished jobs.... [LD] libxlog.la /bin/sh ../libtool --quiet --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -flto -ffat-lto-objects -rpath /lib64 -version-info 0:0:0 -o libxlog.la xfs_log_recover.lo util.lo make: *** [Makefile:92: default] Error 2 * ERROR: sys-fs/xfsprogs-5.4.0-r1::gentoo failed (compile phase): * emake failed