Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 559280 - CPU_FLAGS_X86 should not be set in stage3 make.conf
Summary: CPU_FLAGS_X86 should not be set in stage3 make.conf
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Configuration (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 608060 (view as bug list)
Depends on: 608058
Blocks:
  Show dependency tree
 
Reported: 2015-08-31 21:36 UTC by Rick Farina (Zero_Chaos)
Modified: 2018-01-10 14:17 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rick Farina (Zero_Chaos) gentoo-dev 2015-08-31 21:36:39 UTC
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.
Comment 1 Zac Medico gentoo-dev 2015-08-31 22:13:46 UTC
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.
Comment 2 Zac Medico gentoo-dev 2015-08-31 22:15:40 UTC
(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.
Comment 3 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2015-09-01 00:09:15 UTC
(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.
Comment 4 Rick Farina (Zero_Chaos) gentoo-dev 2015-09-01 02:45:31 UTC
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"
Comment 5 Ben Kohler gentoo-dev 2016-11-29 15:56:38 UTC
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
Comment 6 SpanKY gentoo-dev 2016-11-29 17:00:15 UTC
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.
Comment 7 Ben Kohler gentoo-dev 2017-01-09 22:15:27 UTC
Catalyst team please fix this, there is no reason catalyst needs to touch this variable in its make.conf
Comment 8 Simon 2017-10-22 18:28:04 UTC
Any progress on this? I'm still running into this issue for my CI setup.
Comment 9 Ben Kohler gentoo-dev 2017-10-22 18:38:54 UTC
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?
Comment 10 Simon 2017-10-22 18:52:25 UTC
(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?
Comment 11 Ben Kohler gentoo-dev 2017-10-22 18:57:15 UTC
*** Bug 608060 has been marked as a duplicate of this bug. ***
Comment 12 Ben Kohler gentoo-dev 2018-01-10 14:17:31 UTC
This is fixed in the last few stage3 builds