It appears that building sys-fs/xfsprogs-5.5.0 with -O3 in CFLAGS results in linking issues [LD] xfs_db /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/portage/tmp/portage/sys-fs/xfsprogs-5.5.0/temp/mkfs.xfs.8vy57a.ltrans0.ltrans.o: warning: relocation against `.L611' in read-only section `.text' /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/portage/tmp/portage/sys-fs/xfsprogs-5.5.0/temp/mkfs.xfs.8vy57a.ltrans0.ltrans.o: in function `libxfs_ialloc.isra.0.constprop.0': <artificial>:(.text+0x33c5): undefined reference to `.L611' /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object collect2: error: ld returned 1 exit status gmake[2]: *** [../include/buildrules:65: mkfs.xfs] Error 1 gmake[1]: *** [include/buildrules:35: mkfs] Error 2 gmake[1]: *** Waiting for unfinished jobs.... /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/portage/tmp/portage/sys-fs/xfsprogs-5.5.0/temp/xfs_repair.p2FWHq.ltrans1.ltrans.o: warning: relocation against `.L366' in read-only section `.text' /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/portage/tmp/portage/sys-fs/xfsprogs-5.5.0/temp/xfs_repair.p2FWHq.ltrans1.ltrans.o: in function `libxfs_iget.constprop.0': <artificial>:(.text+0x19f0): undefined reference to `.L366' /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object collect2: error: ld returned 1 exit status gmake[2]: *** [../include/buildrules:65: xfs_repair] Error 1 gmake[1]: *** [include/buildrules:35: repair] Error 2 /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/portage/tmp/portage/sys-fs/xfsprogs-5.5.0/temp/xfs_db.L84FqC.ltrans0.ltrans.o: warning: relocation against `.L2156' in read-only section `.text' /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/portage/tmp/portage/sys-fs/xfsprogs-5.5.0/temp/xfs_db.L84FqC.ltrans0.ltrans.o: in function `libxfs_iget.constprop.0': <artificial>:(.text+0x70a1): undefined reference to `.L2156' /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object collect2: error: ld returned 1 exit status gmake[2]: *** [../include/buildrules:65: xfs_db] Error 1 gmake[1]: *** [include/buildrules:35: db] Error 2 make: *** [Makefile:92: default] Error 2 * ERROR: sys-fs/xfsprogs-5.5.0::gentoo failed (compile phase): Once changed to -O2, everything works. This is on fully updated ~amd64 system with CFLAGS="-O3 -pipe -march=znver2"
This looks like maybe an LTO related problem?
I am having this with -O2 too
Sorry forget that I didn't look right. I have -O3 too.
Problem persists in sys-fs/xfsprogs-5.6.0.
Same for me on 5.6.0 and -O3
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9f48774c6b67f91e120b1e993820f981a9161d71 commit 9f48774c6b67f91e120b1e993820f981a9161d71 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2020-04-18 12:39:39 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2020-04-18 12:39:39 +0000 sys-fs/xfsprogs: Build fails with -O3. Replaced with -O2 Closes: https://bugs.gentoo.org/712698 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> sys-fs/xfsprogs/xfsprogs-5.5.0.ebuild | 3 +++ sys-fs/xfsprogs/xfsprogs-5.6.0.ebuild | 3 +++ 2 files changed, 6 insertions(+)
Instead of just ignoring peoples' CFLAGS from now on... can someone experiencing this problem try to figure out which commit introduced the breakage? I mentioned this bug on IRC (#xfs in freenode) and this was the response: <sandeen> mjo, is that a regression? <sandeen> doubt it's related to any xfsprogs change but if you can narrow it down to one ,let us know on the list please
Re-opening since this isn't really "fixed".
This is indeed triggered by the combination of -O3 and LTO.
(In reply to Michael Orlitzky from comment #7) > Instead of just ignoring peoples' CFLAGS from now on... can someone > experiencing this problem try to figure out which commit introduced the > breakage? a0264b735a2eb7aa9ea744d917b6d66cdfe94bcc is the first bad commit commit a0264b735a2eb7aa9ea744d917b6d66cdfe94bcc Author: Darrick J. Wong <darrick.wong@oracle.com> Date: Wed Jan 22 11:29:37 2020 -0500 xfs: always log corruption errors Source kernel commit: a5155b870d687de1a5f07e774b49b1e8ef0f6f50 Make sure we log something to dmesg whenever we return -EFSCORRUPTED up the call stack. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Eric Sandeen <sandeen@sandeen.net> libxfs/libxfs_priv.h | 2 ++ libxfs/util.c | 13 +++++++++++++ libxfs/xfs_alloc.c | 9 +++++++-- libxfs/xfs_attr_leaf.c | 12 +++++++++--- libxfs/xfs_bmap.c | 8 +++++++- libxfs/xfs_btree.c | 5 ++++- libxfs/xfs_da_btree.c | 24 ++++++++++++++++++------ libxfs/xfs_dir2.c | 4 +++- libxfs/xfs_dir2_leaf.c | 4 +++- libxfs/xfs_dir2_node.c | 12 +++++++++--- libxfs/xfs_inode_fork.c | 6 ++++++ libxfs/xfs_refcount.c | 4 +++- libxfs/xfs_rtbitmap.c | 5 +++-- 13 files changed, 87 insertions(+), 21 deletions(-) bisect run success $ git bisect log # bad: [0618c372868777d287168965bbcfe5f963d34893] xfsprogs: Release v5.6.0 # good: [0cfb2952319d237f1d079097810546f24e3883bf] xfsprogs: Release v5.4.0 git bisect start 'master' 'v5.4.0' # bad: [dda1a0a27059ee2d7b2913ff465504d2c808d945] xfsprogs: alphabetize libxfs_api_defs.h git bisect bad dda1a0a27059ee2d7b2913ff465504d2c808d945 # bad: [5e9bc7eef8bf1da148dbf9f3a686b723b8f9dbe4] xfs: remove the data_dot_offset field in struct xfs_dir_ops git bisect bad 5e9bc7eef8bf1da148dbf9f3a686b723b8f9dbe4 # bad: [530bc0fc4799b3edfb5803b9fd6a50ee3c087e07] xfs: null out bma->prev if no previous extent git bisect bad 530bc0fc4799b3edfb5803b9fd6a50ee3c087e07 # good: [b6d2b93c4e45aaca317b0b1723d97e8377e4bf3b] xfs: fix inode fork extent count overflow git bisect good b6d2b93c4e45aaca317b0b1723d97e8377e4bf3b # good: [2ac7663ab1e4c3b0f753e0b50dc8adf18a9bc1ca] xfs: refactor xfs_bmapi_allocate git bisect good 2ac7663ab1e4c3b0f753e0b50dc8adf18a9bc1ca # good: [d11b23b618a137a817a962eaa59e3b8978da6ef0] xfs: relax shortform directory size checks git bisect good d11b23b618a137a817a962eaa59e3b8978da6ef0 # bad: [3af5535c24d13160b3a05d34569affaae2f0e941] xfs: decrease indenting problems in xfs_dabuf_map git bisect bad 3af5535c24d13160b3a05d34569affaae2f0e941 # bad: [a0264b735a2eb7aa9ea744d917b6d66cdfe94bcc] xfs: always log corruption errors git bisect bad a0264b735a2eb7aa9ea744d917b6d66cdfe94bcc # first bad commit: [a0264b735a2eb7aa9ea744d917b6d66cdfe94bcc] xfs: always log corruption errors
(In reply to Matt Whitlock from comment #10) I can confirm that bisect result.
Just a guess but I think it might be the function defined in xfs_error.c that's the problem (and how the symbols are exported). Most everything else is a macro for that calls into a logging function that was already there. It also seems that upstream moved where that file is defined (in the master branch, anyway).
