Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 164923 - media-libs/imlib2 - amd64 optimizations are never enabled
Summary: media-libs/imlib2 - amd64 optimizations are never enabled
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: AMD64 Project
URL:
Whiteboard:
Keywords:
: 166348 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-02-01 22:12 UTC by Marcin Kowalski
Modified: 2007-02-11 14:26 UTC (History)
2 users (show)

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


Attachments
patch imlib2-1.3.0.ebuild to use --enable-amd64 properly (imlib2-amd64-mmx.patch,682 bytes, patch)
2007-02-04 14:20 UTC, Matthew Smith
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Kowalski 2007-02-01 22:12:36 UTC
i just noticed that both imlib2 ebuild from portage (tried on 1.3.0) and -9999 ebuild from vapier's overlay don't enable amd64 specific optimizations, even if amd64 architecture is detected.

the source of the problem is here (line taken from both ebuilds)

$(use_enable mmx amd64) --disable-mmx

should be 

$(use_enable amd64) --disable-mmx

it seems that use_enable can take only 1 arg at a time. 

i thought that some overlay eclasses could be getting in the way, so i disabled overlays completely. result is the same.

are amd64 optimizations safe enough to be used with imlib2, or is this some kind of attempt to disable them, out of pure stability reasons?
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-02-02 09:14:37 UTC
(In reply to comment #0)
> $(use_enable mmx amd64) --disable-mmx
> it seems that use_enable can take only 1 arg at a time. 

Uh no... The above means that amd64 optimizations will be enabled when USE=mmx is set.
Comment 2 Marcin Kowalski 2007-02-02 12:58:55 UTC
i have USE="mmx" all the time and neither optimizations are being enabled.
Comment 3 Marcin Kowalski 2007-02-03 12:07:58 UTC
maybe that's because amd64 profile disables mmx and similar flags? (they show as (-flag) when you run emerge -pv ), e.g. 

[ebuild     R ] media-libs/imlib2-1.3.0 USE="X bzip2 gif jpeg mp3 nls png tiff zlib -doc (-mmx)" 0 kB 

even though i enabled them in make.conf

make.conf 
USE=" (... ) \
     matroska mbox md5sum metalink mhash mmkeys mmx mmxext mng \
 (...)"

--------------------------
# eselect profile list
Available profile symlink targets:
  [1]   default-linux/amd64/2006.1
  [2]   default-linux/amd64/2006.1/desktop *
  [3]   default-linux/amd64/2006.0/no-symlinks
  [4]   default-linux/amd64/2006.1/no-multilib
  [5]   hardened/amd64
  [6]   hardened/amd64/multilib
  [7]   selinux/amd64/2006.1
Comment 4 Matthew Smith 2007-02-04 14:20:47 UTC
Created attachment 109127 [details, diff]
patch imlib2-1.3.0.ebuild to use --enable-amd64 properly

the current ebuild behavior is indeed incorrect since the processor feature USE flags are masked on amd64.
Comment 5 Simon Stelling (RETIRED) gentoo-dev 2007-02-04 14:24:17 UTC
This is because we're in a transitionary phase right now. portage-2.1.2 includes some features that give us more finegraded control over the assembler USE flags, thus they are generally masked but unmasked/enabled where possible. Upgrade your portage to a testing version or wait until that version gets marked stable to get assembler optimizations again.
Comment 6 Matthew Smith 2007-02-04 21:21:31 UTC
even with portage-2.1.2-r7, imlib2 is not built with --enable-amd64 at this time. Please reopen, or tell me if I'm missing something.
Comment 7 Simon Stelling (RETIRED) gentoo-dev 2007-02-04 22:15:34 UTC
Sorry, you were right, they are still masked. I didn't unmask them when I tested all the packages because imlib2 was broken at that time. 1.3.0 seems to work fine though, so mmx is unmasked for it now.
Comment 8 Simon Stelling (RETIRED) gentoo-dev 2007-02-04 22:15:45 UTC
bug fixed
Comment 9 Jakub Moc (RETIRED) gentoo-dev 2007-02-11 14:26:03 UTC
*** Bug 166348 has been marked as a duplicate of this bug. ***