Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 77494 - Several Assembler -USE flags missing in profile/default-linux/amd64/use.mask
Summary: Several Assembler -USE flags missing in profile/default-linux/amd64/use.mask
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: AMD64 Project
Depends on:
Blocks: 84488
  Show dependency tree
Reported: 2005-01-11 02:48 UTC by Roland Bär
Modified: 2005-03-11 06:32 UTC (History)
0 users

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


Note You need to log in before you can comment on or make changes to this bug.
Description Roland Bär 2005-01-11 02:48:10 UTC
The USE flags mmx, mmx2, sse, sse2, 3dnow, 3dnowex are hard masked on
amd64/Linux. No ebuild will use them.
Blocks also Bug #76521

Reproducible: Always
Steps to Reproduce:
1. emerge -pv gimp
    => no mmx enabled
2. Adding following to /usr/portage/profiles/default-linux/amd64/use.mask
# Unmask x86 instruction sets (taken from ../x86/use.mask)

This assumed to be the correct fix. These flags are generally disabled for Linux,
then generally enabled for linux->x86. They should then also be generally be enabled 
for linux->amd64

Actual Results:  
[ebuild   R   ] media-gfx/gimp-2.0.4  +aalib (-altivec) -debug +doc -gimpprint +jpeg (-mmx) +mng 
+png +python (-sse) +svg +tiff +wmf 0 kB 
You see (-mmx), (-sse) no matter whats in /etc/make.conf or /etc/portage/

Expected Results:  
[ebuild   R   ] media-gfx/gimp-2.0.4  +aalib (-altivec) -debug +doc -gimpprint +jpeg +mmx* +mng 
+png +python +sse* +svg +tiff +wmf 0 kB
You see +mms, +sse

Portage 2.0.51-r3 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-, 2.6.10 x86_64)
System uname: 2.6.10 x86_64 Mobile AMD Athlon 64 Processor 2800+
Gentoo Base System version 1.5.3
Autoconf: sys-devel/autoconf-2.59-r5,sys-devel/autoconf-2.13
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-
Headers:  sys-kernel/linux26-headers-
Libtools: sys-devel/libtool-1.5.2-r7
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/
kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/
dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/
texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox"
USE="amd64 3dnow 3dnowex X aac aalib accessibility acpi alsa audiofile berkdb bitmap-fonts blender-
game bluetooth bonobo bzlib c++ cairo cddb cdparanoia cdr cgi cjk cross crypt cups directfb 
divx4linux doc dri dvd dvdr dvdread edl emacs emacs-w3 emul-linux-x86 esd ethereal ex f77 fam 
fbcon fftw flac flash flatfile font-server fortran ftp gd gdbm gif ginac glx gmp gphoto2 gpm gstreamer 
gtk gtkhtml imagemagick imap imlib insecure-drivers ipv6 java jp2 jpeg kde lcms leim libwww lirc lzw 
lzw-tiff mad mbox mikmod mime mmx mmx2 mng motif mpi mule multilib ncurses nls offensive 
oggvorbis opengl oss pam pcntl pcre perl php png pnp ppds python qt readline recode samba sdk sdl 
sharedmem simplexml slang sse sse2 ssl svg sysvipc tcltk tcpd tetex theora tiff tokenizer truetype 
truetype-fonts type1-fonts usb userlocales v4l v4l2 vhosts videos wmf xfs xine xinerama xml xml2 
xmms xosd xpm xprint xrandr xv xvid xvmc yv12 zlib video_cards_radeon linguas_en linguas_de"
Comment 1 Mike Doty (RETIRED) gentoo-dev 2005-01-11 13:04:36 UTC
This issue is currently being addressed by the AMD64 team.  the USE flags are masked becuase they usualy enable x86 specific asm code.
Comment 2 Danny van Dyk (RETIRED) gentoo-dev 2005-01-11 13:43:40 UTC
Solved -> Reopen for different solution
Comment 3 Danny van Dyk (RETIRED) gentoo-dev 2005-01-11 13:44:39 UTC
The mentioned USE-Flags are for x86 only. amd64 enabled those part of source by

Comment 4 Roland Bär 2005-01-12 04:58:47 UTC
Referring also to the Bug #76521 solution.

In #76521 Danny wrote "AMD64 Team decided that all packages that support amd64-SIMD assembler will be enabled to use that assembler by default."
I agree with that. Could you comment a reference to the discussion for the decision? Thanx.

But the solution shown up in #76521 is not in the intention of the Gentoo build system,
this simply doesn't enable that using the build system, this simply hardcodes that "enable" in
that ebuild. If we follow that way, we have to review all ebuilds using that flags, and hardcode
that for amd64 in. This is error-pronous and unnecessary work.

The USE game here, as far as I have that understood:
1. /usr/portage/profiles/default-linux/use.mask
   This masks out the flags for Linux generally, e.g
2. /usr/portage/profiles/default-linux/amd64/use.mask 
   Here we have to undo the effect of 1., by adding each flag with a dash
  Now principally any user can add the flags in e.g. /etc/make.conf 
  Same game as similar problem "altivec" on Linux/ppc64
3. As the porting team has decided, to enable that flags per default, the following entry
USE="${GRP_STAGE23_USE} mmx mmx2 sse sse2 3dnow 3dnowex"
  should be added to /usr/portage/profiles/default-linux/amd64/make.defaults

The current #76521 solution is a "get-rid-of-that" solution, not a "enable-per-default" solution
Comment 5 Danny van Dyk (RETIRED) gentoo-dev 2005-01-12 08:30:37 UTC
It's no "get-rif-od-that" solution.

Taking {sse,sse2,mmx,...} out of use.mask would lead to breakage of all
ebuilds that don't check for x86 when they check for the useflags.

USE="sse" means: on _x86_, enable sse-assembler (32bit) for this package.
This would break the build with gcc-error. You can't mix 32bit and 64bit
code like that.

So we had effectively 2 possibilities. Change the build-system to different USE Flags {sse-64,mmx-64,...} or hard-enable them.As there are NO amd64 processors
w/o SIMD support, the choice was hard-enabling it.

If you still want to ask questions or comment on this, please refer to the
gentoo-amd64 mailing-list.
Comment 6 Roland Bär 2005-02-03 06:57:59 UTC
Closing this issue for now, don't agree "invalid"