Summary: | media-libs/libwebp-0.5.1 - error: inlining failed in call to always_inline ‘_mm_cvtepu8_epi16’: target specific option mismatch | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrey <xor29a> |
Component: | Current packages | Assignee: | Gentoo Graphics Project <graphics+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chromium, jan_braun, laurent |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 598208 | ||
Attachments: |
build log
Allow to disable see2 and sse4.1 auto-detection. |
Description
Andrey
2016-09-29 13:27:01 UTC
Created attachment 448418 [details]
build log
Created attachment 452184 [details, diff]
Allow to disable see2 and sse4.1 auto-detection.
I am seeing the problem on a machine that has sse4.1 but is building for a machine which does not. The configure script then enables sse4.1 but this fails to compile with the CFLAGS for the destination cpu.
The attached patch uses the CPU_FLAGS_X86 variable to disable see2 and sse4.1 auto-detection.
As far as I understand it, it does not what one would expect ,i.e., enable sse conditioned on the variable, but instead it disables sse when the variable is not set.
Nonetheless, this patch allows to disable and thus compile in the above scenario.
Yes, you're right. I trying to build on modern PC but use CFLAGS for not so modern. Sorry, I forgot to mention that. I will try to check the patch today and let you know, if it helps. Thank you Yes, the patch helps, thank you! The problem here is triggered by your CFLAGS. They cause the compiler to be called like this: gcc ... -msse4.1 ... -mno-sse4.1 ... So the build system enables sse4.1, but then your CFLAGS disable it. The code calls the CPUID instruction to determine what flags are enabled at runtime; there's no real need to disable the instructions at build time. *** Bug 605500 has been marked as a duplicate of this bug. *** (In reply to Jan-Matthias Braun from comment #2) Thanks, I pushed a similar patch. Disabling the build time detection is strictly unnecessary, but it's probably the easiest way to resolve this. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b804ac8b176f70a0b71ac8dad768f7bb28bd2eda commit b804ac8b176f70a0b71ac8dad768f7bb28bd2eda Author: Mike Gilbert <floppym@gentoo.org> Date: Sat Jan 14 20:11:46 2017 -0500 media-libs/libwebp: add USE flags for avx2, sse2, sse4.1, and neon Bug: https://bugs.gentoo.org/595526 Package-Manager: Portage-2.3.3_p32, Repoman-2.3.1_p25 media-libs/libwebp/libwebp-0.5.2.ebuild | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) Thanks for pushing a fix. Actually, I do think it is necessary to disable build time CPU detection. In my case, I am compiling for a weaker CPU on a different machine. A process, which is in general quite painless with Gentoo. In my experience, you have to disable CPU features which are unavailable on the target machine to get code which executes. So, thanks for supporting this use case! (In reply to Jan-Matthias Braun from comment #8) yep, this is how we're supposed to be writing ebuilds I am pretty sure runtime CPU detection would have worked just as well here. To clarify: the build-time check only verifies that the compiler supports flags like -msse2. It does not look at the CPU installed in the build machine at all. The compiler checks fail due to the -mno-sse2 CFLAGS that you have defined. (In reply to Mike Gilbert from comment #11) thanks for the info. agreed, runtime detection would not be an issue. i'm not sure if we have a USE flag to control support for this though. we've just gone with the CPU_FLAGS route and not worried about it. |