Summary: | net-libs/nodejs-18.7.0:0/18::gentoo fails with CFLAGS="-mno-avx2" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Xavier Miller <xavier.miller> |
Component: | Current packages | Assignee: | William Hubbs <williamh> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | floppym, netbox253 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build log
emerge --info |
Description
Xavier Miller
2022-08-04 08:30:05 UTC
Created attachment 797521 [details]
build log
Created attachment 797524 [details]
emerge --info
Putting "-mno-xxx" in your CFLAGS is generally a bad idea. Instead, just pick an appropriate value for -march. I would guess that nodejs contains AVX2 code that is conditionally invoked at runtime depending on the capabilities CPU it is running on. It needs to enable the appropriate intrinsic functions this one source file via -mavx2, but your CFLAGS are forcing that to be disabled via -mno-avx2. if this is the case that AVX2 code is conditionally loaded at runtime, couldn't we add somme CFLAGS filtering in the ebuild? (In reply to Xavier Miller from comment #4) Yes, but such filter would be unnecessary if users would stop adding -mno-avx2 to there CFLAGS. It really does nothing useful and just causes random build failures like this one. I agree with Mike. There is no way we can filter out all incompatible CFLAGS, so the best thing for users to do is stick with the flags we consider safe. Please see the following page for more information on this subject. https://wiki.gentoo.org/wiki/Safe_CFLAGS Thanks, William BTW the wiki page shows examples with "-mo-avx" and the like flags. I followed the page, and my CFLAGS are the results of gcc -v -E -x c /dev/null -o /dev/null -march=native 2>&1 | grep /cc1 By those -mnoXXX flags I am sure the binpkgs I build are compatible with the old CPUs. If no fix is proposed, I will simplify the CFLAGS through package.env Hmm, I didn't realize Intel made ivybridge chips that lack AVX and other extensions. How confusing. We could add "strip-flags -mno-avx2" to the ebuild, but then you would risk having the compiler emit instructions in other objects that will not run on all CPUs you want to support. To fix this, upstream would need to alter their build system to put -mavx2 after the user's flags for the files where runtime CPU detection is implemented. @Mike Gilbert Having the same issue, I was pointed towards this bug. The status reads RESOLVED UPSTREAM, however, is this wishful thinking or has it indeed been fixed upstream? I'm not sure how to work around this for now, but waiting for a fix maybe in the newly released 19.0.0 would make this obsolete in the first place. Ref: https://forums.gentoo.org/viewtopic-p-8754677.html (In reply to Sven Schwyn (svoop) from comment #9) > @Mike Gilbert > > Having the same issue, I was pointed towards this bug. The status reads > RESOLVED UPSTREAM, however, is this wishful thinking or has it indeed been > fixed upstream? > RESOLVED UPSTREAM doesn't actually mean the problem has been fixed upstream. It means we can't fix the problem in Gentoo, and the problem should be addressed by the upstream developers. > I'm not sure how to work around this for now, but waiting for a fix maybe in > the newly released 19.0.0 would make this obsolete in the first place. You can work around the problem by selecting an -march setting via CFLAGS that does not enable the avx2 instructions. A correction here: The -march=ivybridge option enables AVX, but not AVX2. Having -mno-avx2 in your CFLAGS seems pointless. @Mike Gilbert Thanks for your reply! Turns out, the root of my problem was a rather stupid mistake in the COMMON_FLAGS, but good to know how to interpret "RESOLVED UPSTREAM" in the future. *** Bug 906604 has been marked as a duplicate of this bug. *** |