Summary: | media-tv/mythtv-31.0_p20210225 failed to emerge [-fpermissive] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Leonid Kopylov <leonchik1976> |
Component: | Current packages | Assignee: | Wilson M. Michaels <thebitpit> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | jstein, neil, proxy-maint, sam |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/21878 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log.xz |
Description
Leonid Kopylov
2021-05-19 12:42:24 UTC
Created attachment 709788 [details]
build.log.xz
I just hit this. I suspect it's caused by compiling some dependency with gcc-11 instead of gcc-10. I found that upgrading from gcc-10.2 to gcc-10.3 caused my default compiler to change to gcc-11, which I wasn't expecting. I have four systems that are completely current with all packages, but I only hit this on one of them. Somehow the configure script is deciding that the math function lrint() doesn't exist, so it's setting HAVE_LRINT to 0, which in turn tells a .h file to define a static version (after the system include file has pulled in the external prototype). If I'm understanding the configure script correctly, it will reject the system lrint() if it's not there or if it doesn't function correctly, and I'm guessing it's the functionality test. To test the gcc-11 theory, I uninstalled gcc-11 and then rebuilt every package that was installed between when it was installed and when it was removed. That didn't change the behavior at all. The three systems where this installs just fine are fairly normal systems with lots of stuff installed. The one where it fails is a very minimal system that is mostly going to be a headless backend, so it doesn't have much besides the dependencies. It's possible this problem is an implicit dependency somewhere. I'm trying media-tv/mythtv-31.0_p20210606, so the 2021/06/06 version has the same issue as the 2021/02/25 version. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=144bb5a4ee836842eb9fc73f597b0a2ab3228584 commit 144bb5a4ee836842eb9fc73f597b0a2ab3228584 Author: Wilson Michaels <thebitpit@austincustomerrands.com> AuthorDate: 2021-08-04 15:21:07 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-08-10 16:22:12 +0000 media-tv/mythtv: remove old snapshots Closes: https://bugs.gentoo.org/791088 Package-Manager: Portage-3.0.20, Repoman-3.0.2 Signed-off-by: Wilson Michaels <thebitpit@austincustomerrands.com> Closes: https://github.com/gentoo/gentoo/pull/21878 Signed-off-by: Joonas Niilola <juippis@gentoo.org> media-tv/mythtv/Manifest | 2 - media-tv/mythtv/mythtv-31.0_p20210225.ebuild | 435 --------------------------- media-tv/mythtv/mythtv-31.0_p20210606.ebuild | 435 --------------------------- 3 files changed, 872 deletions(-) I'm still hitting this with mythtv-31.0_p20210731. I'm not sure why this fails on some systems and not others. Things to try to fix your problem: Upgrade to latest stable sys-libs/glibc [2.33-r1] tgmath.h defines lrint() and is owned by sys-libs/glibc Rebuild tool chain as described in https://wiki.gentoo.org/wiki/Upgrading_GCC This is important since you moved from gcc-10 to gcc-11. Of all my suggestions this one might actually fix your problem. I use gcc 10.3.0-r2, and mythtv is known to compile with gcc-11 [tinderbox] Maybe recompile the kernel since it was built with an older version of glibc. Since mythtv is OK on other systems you own, I suspect that the toolchain on the failing system is not consistent. I've rebuilt the toolchain. I long ago looked in emerge.log for when I emerged gcc-11 and unmerged it, and rebuilt anything that was merged while it was on the system (based on directory timestamps in /var/db/pkg/*-*/*). I just rebuilt the tools and glibc, still the same. My gut tells me that there's some missing package that somehow fixes this, since this is only a problem for me on this very minimal headless system. Years ago you could build mythfrontend and mythbackend separately controlled by USE flags. The gentoo devs did not like that and required the maintainer at that time (not me) remove the USE flags and build both every time. Since the system is headless, trying to build mythfrontend may be causing the problem (just a guess). I've found the problem: In the configure script, there's the code: # test for lrint in math.h check_exec <<EOF && lrint=yes || die lrint=no #define _ISOC9X_SOURCE 1 #include <math.h> int main( void ) { return (lrint(3.999f) > 0)?0:1; } EOF That should work, but on my system is generating an illegal instruction. By adding some logging and running the configure script manually, here's the command that it's using to build the code: x86_64-pc-linux-gnu-gcc -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -O3 -pipe -march=native -mtune=native -fomit-frame-pointer -fno-stack-protector -march=haswell -std=c11 -fPIC -pthread -I/usr/include/libxml2 -I/usr/include/libdrm -c -o /tmp/ffconf.7J6LenK5/test.o /tmp/ffconf.7J6LenK5/test.c x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -march=haswell -Wl,--as-needed -Wl,-z,noexecstack -o /tmp/ffconf.7J6LenK5/test /tmp/ffconf.7J6LenK5/test.o -lm -lhdhomerun -lhdhomerun -ldrm -lxml2 -lmp3lame -lm -lz -pthread -pthread -lsamplerate The problem is that I have a Celeron Haswell processor, and the above uses -march=haswell overriding -march=native, which enables instructions for Haswell that are not included with the Celleron. diff -u <(gcc -march=haswell -Q --help=target) <(gcc -march=native -Q --help=target) - -mabm [disabled] + -mabm [enabled] - -mavx [enabled] - -mavx2 [enabled] + -mavx [disabled] + -mavx2 [disabled] - -mbmi [enabled] - -mbmi2 [enabled] + -mbmi [disabled] + -mbmi2 [disabled] - -mf16c [enabled] + -mf16c [disabled] - -mfma [enabled] + -mfma [disabled] - -mxsave [enabled] + -mxsave [disabled] - -mxsaveopt [enabled] + -mxsaveopt [disabled] gcc --version gcc (Gentoo 10.3.1_p20211126 p0) 10.3.1 20211126 In this case, if I add -mno-avx to the command line after the -march=haswell, then it works. This is consistent with the Wikipedia page on AVX: https://en.wikipedia.org/wiki/Advanced_Vector_Extensions "Not all CPUs from the listed families support AVX. Generally, CPUs with the commercial denomination Core i3/i5/i7/i9 support them, whereas Pentium and Celeron CPUs do not." Disassembly of the code in gdb shows it fails on the vmovq instruction, which is in the AVX instructions. In the configure script, it insists on setting the architecture. if test "$cpu" = host; then enabled cross_compile && die "--cpu=host makes no sense when cross-compiling." case "$cc_type" in gcc|llvm_gcc) check_native(){ $cc $1=native -v -c -o $TMPO $TMPC >$TMPE 2>&1 || return sed -n "/cc1.*$1=/{ s/.*$1=\\([^ ]*\\).*/\\1/ p q }" $TMPE } cpu=$(check_native -march || check_native -mcpu) ;; ... elif enabled x86; then case $cpu in ... # targets that do support nopl and conditional mov (cmov) i686|pentiumpro|pentium[23]|pentium-m|athlon|athlon-tbird|athlon-4|athlon-[mx]p|athlon64*|k8*|opteron*|athlon-fx\ |core*|atom|bonnell|nehalem|westmere|silvermont|sandybridge|ivybridge|haswell|broadwell|skylake*|knl\ |amdfam10|barcelona|b[dt]ver*|znver*) cpuflags="-march=$cpu" Just change -march=$cpu to -march=native on that last line, and it all works. Now the question is whether this should be fixed in the configure script, or if we should fix gcc to only use instructions in -march=haswell that are available on all Haswell processors (and similarly on other architectures)? |