| Summary: | sys-fs/xfsprogs-5.2.1 - ld: undefined reference[s] to `crc32c_le' `list_sort' `platform_align_blockdev' `platform_check_ismounted' `platform_check_iswritable' `platform_direct_blockdev' `platform_findblockpath' `platform_findrawpath' `platform_findsi[...] | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | guillaume, shawnanastasio |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
sys-fs:xfsprogs-5.2.0:20190820-085949.log
sys-fs:xfsprogs-5.2.1:20191104-102927.log |
||
|
Description
Jeroen Roovers (RETIRED)
2019-08-20 09:22:48 UTC
We probably have to report this upstream. Before we can do that we need to make sure that no patches are causing the problem and if this is new in 5.2.0 due to our changed ebuild (which will match upcoming 5.3.0), new in 5.2.0 in general or already not working in 5.1.0 but hidden due to --disable-static/our patches. Please do the following things and report back: 1) Unpack xfsprogs-5.2.0.tar.xz 2) cd into unpacked src. 3) Run CFLAGS="$(portageq envvar CFLAGS)" \ LDFLAGS="$(portageq envvar LDFLAGS)" \ ./configure" 4) `unset LDFLAGS` (there's a bug in build system and duplicated LDFLAGS could cause problems) 5) `make V=1` Repeat the same with xfsprogs-5.1.0. Now tell us if vanilla xfsprogs-5.2.0 shows the same failure (attach build text output in this case) and if *vanilla xfsprogs-5.1.0* works or is already failing. Hi, please either do not close bug reports just because you want more information, or instead fix bugzilla so that closed bugs can be found more easily. Vanilla 5.2.0 compiles fine. I will repeat with the native CFLAGS I normally use, just to see if that changes anything. I don't seem to run into any problems working outside the 5.2.0 ebuild. Thanks, could you please drop xfsprogs-4.9.0-underlinking.patch patch and retry? That seems to be the only patch affecting libxfs. Hi! I am seeing lots of undefined references on my raspberry pi when emerging xfsprogs 5.2.0, at least platform_align_blockdev is also in the long list.
I tried:
(1) Compiling the source manually. This works perfectly.
(2) Removing all PATCHES from the ebuild. This compiles, installs, but doesn't merge with
* QA Notice: Missing gen_usr_ldscript for libhandle.so
* ERROR: sys-fs/xfsprogs-5.2.0::gentoo failed:
* add those ldscripts
*
* Call stack:
* misc-functions.sh, line 586: Called install_qa_check
* misc-functions.sh, line 132: Called source 'install_symlink_html_docs'
* 80libraries, line 178: Called lib_check
* 80libraries, line 153: Called die
* The specific snippet of code:
* [[ ${abort} == "yes" ]] && die "add those ldscripts"
(3) When adding the sharedlibs.patch (only) I am back to the original behaviour showing all the undefined references.
On my Intel machine, xfsprogs-5.2.0 is emerging nicely.
I can confirm that this issue is present on ppc64le with xfsprogs 5.2.0 and 5.2.1. Removing xfsprogs-4.9.0-underlinking.patch does not resolve the issue. I see the same errors on my raspberry pi3 64bit with xfsprogs-5.2.1. The latest successfull compiled version was 5.1.0 here. (In reply to Thomas Deutschmann from comment #6) > Thanks, could you please drop xfsprogs-4.9.0-underlinking.patch patch and > retry? That seems to be the only patch affecting libxfs. While it's true that it's the only patch affecting libxfs, removing it just reveals different problems. I am sorry but I still have no system where I can reproduce the failure so I don't know what to do. At the moment I am waiting for xfsprogs-5.3.0 which will have more changes and will complete sharedlibs removal which started in 5.2.1. Created attachment 595036 [details] sys-fs:xfsprogs-5.2.1:20191104-102927.log (In reply to Thomas Deutschmann from comment #11) > I am sorry but I still have no system where I can reproduce the failure so I > don't know what to do. At the moment I am waiting for xfsprogs-5.3.0 which > will have more changes and will complete sharedlibs removal which started in > 5.2.1. I can "reproduce" it on amd64 now, but the errors are interestingly different. [ebuild N ~] sys-fs/xfsprogs-5.2.1::gentoo USE="nls readline -icu -libedit" 0 KiB One avenue to resolution might be to look into this build log: where no xfsprogs is yet installed it fails interestingly as it cannot find libxfs: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lxfs Looks like libtool is looking for a library installed to the live system. This would also explain that in earlier reports the linker fails to find certain symbols, as those might be present in the to-be-installed libraries but not in the already installed libraries. (In reply to Jeroen Roovers from comment #12) > /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ > ld: cannot find -lxfs > > Looks like libtool is looking for a library installed to the live system. > This would also explain that in earlier reports the linker fails to find > certain symbols, as those might be present in the to-be-installed libraries > but not in the already installed libraries. I've stumbled upon the same, on systems which didn't yet have xfsprogs installed. However, interestingly enough, forcing MAKEOPTS=-j1 made the problem go away. Seems it could be a weird bug in the build system, trying to use the system's libxfs if and only if it can't find its own, already built inside of the build directory. I am able to reproduce jer's latest finding in an empty stage3. I can confirm that using MAKEOPTS=-j1 will avoid that failure. Anyways, I will wait for xfsprogs-5.3 before I'll look into this again (release should be around the corner). (In reply to Thomas Deutschmann from comment #14) > I am able to reproduce jer's latest finding in an empty stage3. > I can confirm that using MAKEOPTS=-j1 will avoid that failure. Perhaps you meant to provide this comment on bug #694886? It surely does not apply to the bug reported here, which is that xfsprogs links against the installed library instead of the built-but-not-installed library, failing to find symbols (see Summary). Setting MAKEOPTS=-j1 does not fix *this* bug. [ebuild U ] sys-fs/xfsprogs-5.2.1::gentoo [5.1.0::gentoo] USE="nls readline -icu -libedit (-split-usr%*) (-static-libs%)" 0 KiB The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=40f3e79bc23323817848b83571ad91ba3393d100 commit 40f3e79bc23323817848b83571ad91ba3393d100 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-11-18 19:11:20 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-11-18 19:11:59 +0000 sys-fs/xfsprogs: bump to v5.3.0 Closes: https://bugs.gentoo.org/694886 Closes: https://bugs.gentoo.org/692596 Package-Manager: Portage-2.3.79, Repoman-2.3.18 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> sys-fs/xfsprogs/Manifest | 1 + sys-fs/xfsprogs/files/xfsprogs-5.3.0-libdir.patch | 28 ++++++ sys-fs/xfsprogs/xfsprogs-5.3.0.ebuild | 107 ++++++++++++++++++++++ 3 files changed, 136 insertions(+) Please test =xfsprogs-5.3.0. If this will work, I'll drop 5.2.1 very soon or restore previous version. (In reply to Thomas Deutschmann from comment #17) > Please test =xfsprogs-5.3.0. If this will work, I'll drop 5.2.1 very soon or > restore previous version. Yes, this one works. |