Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 740874 - 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
Summary: sys-fs/xfsprogs-5.4.0-r1 - ld: init.o (symbol from plugin): in function `prog...
Status: RESOLVED DUPLICATE of bug 705904
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Blocks: -fno-common gcc-10-stable
  Show dependency tree
Reported: 2020-09-07 17:32 UTC by ernsteiswuerfel
Modified: 2021-01-03 02:13 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

build.log (xfsprogs-5.4.0-r1:20200907-152514.log,58.88 KB, text/plain)
2020-09-07 17:32 UTC, ernsteiswuerfel
emerge --info (file_740874.txt,6.92 KB, text/plain)
2020-09-07 17:33 UTC, ernsteiswuerfel

Note You need to log in before you can comment on or make changes to this bug.
Description ernsteiswuerfel 2020-09-07 17:32:33 UTC
Created attachment 658970 [details]

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/  
/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
/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 command.lo input.lo help.lo quit.lo -lreadline 
/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 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....
/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 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
Comment 1 ernsteiswuerfel 2020-09-07 17:33:15 UTC
Created attachment 658972 [details]
emerge --info
Comment 2 Kerin Millar 2021-01-01 21:57:27 UTC
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.
Comment 3 Lars Wendler (Polynomial-C) gentoo-dev 2021-01-03 00:45:05 UTC

*** This bug has been marked as a duplicate of bug 705904 ***
Comment 4 Kerin Millar 2021-01-03 01:39:05 UTC
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.
Comment 5 Mike Gilbert gentoo-dev 2021-01-03 02:05:18 UTC
xfsprogs-5.10.0 is being stabilized in bug 762961.
Comment 6 Kerin Millar 2021-01-03 02:10:32 UTC
(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.