| Summary: | CPU_FLAGS_X86 should not be set in stage3 make.conf | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Rick Farina (Zero_Chaos) <zerochaos> |
| Component: | Core - Configuration | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bkohler, catalyst, josef64, mgorny, releng, simon.vanderveldt+gentoo |
| Priority: | Normal | ||
| Version: | 2.2 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=530222 https://bugs.gentoo.org/show_bug.cgi?id=627884 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 608058 | ||
| Bug Blocks: | |||
USE_EXPAND variables behave like incremental variables in make.defaults. OTOH, long-standing make.conf behavior is for USE_EXPAND variable settings to negate any profile settings for the variable in question. For example, this allows a user to set VIDEO_CARDS in make.conf and that will negate any VIDEO_CARDS settings that came from the profile. (In reply to Rick Farina (Zero_Chaos) from comment #0) > Now, with the new USE_EXPAND the catalyst setting appears > to completely override the profile, and causes issues. It could use /etc/portage/profile/make.defaults to get incremental behavior. (In reply to Zac Medico from comment #2) > (In reply to Rick Farina (Zero_Chaos) from comment #0) > > Now, with the new USE_EXPAND the catalyst setting appears > > to completely override the profile, and causes issues. > > It could use /etc/portage/profile/make.defaults to get incremental behavior. Zac, our (releng) goal is twofold: 1. set some base sane values, for example "mmx sse sse2" for x86/amd64 (this would work as a safeguard) 2. serve as a documentation on how to use it in make.conf Given your example of VIDEO_CARDS, perhaps we should drop the first goal and accomplish the second with a commented entry and short explanation of how it overrides profile settings and suggesting using app-portage/cpuinfo2cpuflags to set CPU_FLAGS_X86. In this instance it is 100% my vote to add an appropriate comment in make.conf and let the profiles take over (where appropriate). If this idea is approved I would imagine something like this #To take advantage of the instructions in your cpu it is recommended to install #app-portage/cpuinfo2cpuflags and add the line it generates like this: #CPU_FLAGS_X86="mmx mmxext sse sse2" Profiles are currently setting a better more accurate value than what amd64 stage3's make.conf default has, let's move forward with commenting or removing this from stage3 i'm strongly of the opinion that default/sane values should live in the profile, and catalyst should rarely override any of them instead of shipping a largely blank make.conf, catalyst should be updated to use the default portage make.conf and blend in its specific settings. this way we can maintain a central location w/comments (portage) w/out duplicating things in catalyst itself. Catalyst team please fix this, there is no reason catalyst needs to touch this variable in its make.conf Any progress on this? I'm still running into this issue for my CI setup. This is actually fixed in catalyst but not yet in a released version. I opened bug 608058 to track issues which will be resolved once a new release is out. Depending on that is bug 608060 which is pretty much the same issue as this bug, do you think this one needs to stay open? (In reply to Ben Kohler from comment #9) > This is actually fixed in catalyst but not yet in a released version. I > opened bug 608058 to track issues which will be resolved once a new release > is out. Depending on that is bug 608060 which is pretty much the same issue > as this bug, do you think this one needs to stay open? OK, nice to see a tracker bug for the catalyst update! I did notice this bug isn't listed there. One bug report should be enough for this specific issue ;) Since this bug has a bit more history/comments that 60860 I guess it makes more sense to keep this one open? *** Bug 608060 has been marked as a duplicate of this bug. *** This is fixed in the last few stage3 builds |
I recently ran into an usual issue while building some packages in catalyst: !!! The ebuild selected to satisfy ">=media-video/ffmpeg-1.2:0/54.56.56=" has unmet requirements. - media-video/ffmpeg-2.6.3::gentoo USE="X aac alsa bzip2 encode gpl gsm hardcoded-tables iconv jack lzma mp3 network opengl opus oss pic postproc pulseaudio samba sdl speex theora threads truetype vdpau vorbis x264 xcb xvid zlib -aacplus (-altivec) -amr -amrenc (-armv5te) (-armv6) (-armv6t2) (-armvfp) -bluray -bs2b -cdio -celt -cpudetection -debug -doc -examples -faac -fdk -flite -fontconfig -frei0r -fribidi -gme -gnutls -iec61883 -ieee1394 -jpeg2k -ladspa -libass -libcaca -librtmp -libsoxr -libv4l (-mipsdspr1) (-mipsdspr2) (-mipsfpu) -modplug (-neon) -openal -openssl -quvi -schroedinger -ssh -static-libs -test -twolame -v4l -vaapi -vpx -wavpack -webp -x265 -zvbi" ABI_X86="32 64 -x32" CPU_FLAGS_X86="mmx sse sse2 -3dnow -3dnowext -avx -avx2 -fma3 -fma4 -mmxext -sse3 -sse4_1 -sse4_2 -ssse3 -xop" FFTOOLS="aviocat cws2fws ffescape ffeval ffhash fourcc2pixfmt graph2dot ismindex pktdumper qt-faststart trasher" The following REQUIRED_USE flag constraints are unsatisfied: cpu_flags_x86_sse? ( cpu_flags_x86_mmxext ) This is a reasonably odd error, due to the fact that the profile actually set cpu_flags_x86_mmxext for both amd64 and x86 This appears to be cause by catalyst setting CPU_FLAGS_X86 like this: CPU_FLAGS_X86="mmx sse sse2" This was converted from the earlier standard use flags, but there is a problem. In the old days when these were just normal use flags, adding USE="mmx sse sse2" the profile use flags would be additive and fill in the missing mmxext. Now, with the new USE_EXPAND the catalyst setting appears to completely override the profile, and causes issues. While I personally think all this is fine, and amended catalyst to deal with this, the releng team asked me to open a bug to further explore if this is the behavior we all want to agree on.