why i should set sse at all? it let me neither deactivate this sse USE or activiate it. could it be a bug? Reproducible: Always Portage 2.2.14 (python 3.3.5-final-0, default/linux/amd64/13.0/desktop, gcc-4.8.3, glibc-2.19-r1, 3.17.1-gentoo-r1 x86_64) ================================================================= System uname: Linux-3.17.1-gentoo-r1-x86_64-Intel-R-_Core-TM-_i7-3740QM_CPU_@_2.70GHz-with-gentoo-2.2 KiB Mem: 24626960 total, 22334980 free KiB Swap: 25461756 total, 25461756 free Timestamp of tree: Thu, 23 Oct 2014 22:30:01 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.3_p30 dev-java/java-config: 2.2.0 dev-lang/perl: 5.20.1-r1 dev-lang/python: 2.7.8, 3.3.5-r1, 3.4.2 dev-util/cmake: 3.0.2 dev-util/pkgconfig: 0.28-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.13.1 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.14.1 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.8.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.1-r1 sys-kernel/linux-headers: 3.17 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo bitcoin steam-overlay bumblebee printer-drivers lokal ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=corei7 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.6/ext-active/ /etc/php/cgi-php5.6/ext-active/ /etc/php/cli-php5.6/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=corei7 -O2 -pipe" DISTDIR="/mnt/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="de_DE.UTF-8" LC_ALL="" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PKGDIR="/mnt/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/mnt/portage"
Created attachment 387276 [details] build.log
gcc -march=${MARCH} -Q --help=target | grep "msse" | grep "enabled" # gcc -march=x86_64 -Q --help=target | grep sse | grep enabled -mno-sse4 [enabled] Oh look, I broke it. Why is it running gcc directly, anyway?
i run $ gcc -march=x86_64 -Q --help=target | grep sse | grep enabled i got outpot: -mno-sse4 [enabled] but ardour dont compile, so there must really something broken in the ebuild.
You would probably want to do something like this: --- ardour-3.5.403.ebuild 23 Oct 2014 18:13:02 -0000 1.1 +++ ardour-3.5.403.ebuild 24 Oct 2014 06:43:03 -0000 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/media-sound/ardour/ardour-3.5.403.ebuild,v 1.1 2014/10/23 18:13:02 nativemad Exp $ -EAPI=4 +EAPI=5 inherit eutils toolchain-funcs flag-o-matic waf-utils DESCRIPTION="Digital Audio Workstation" @@ -20,6 +20,7 @@ fi LICENSE="GPL-2" SLOT="3" IUSE="altivec debug doc nls lv2 sse" +REQUIRED_USE="sse" RDEPEND="media-libs/aubio media-libs/liblo @@ -68,13 +69,6 @@ DEPEND="${RDEPEND} DEPEND="${DEPEND}" fi -pkg_pretend() { - MARCH=$(get-flag march) - if ! gcc -march=${MARCH} -Q --help=target | grep "msse" | grep "enabled" >/dev/null; then - die "Ardour fails to build with an march that is not sse capable!" - fi -} - src_unpack() { if [ ${PV} = 9999 ]; then git-2_src_unpack but you would have to strip out USE=altivec (was PowerPC support dropped?) in that case. It's probably worth investigating why the build fails without SSE support in the first place, and then fix that instead, if possible.
"Ardour fails to build with an march that is not sse capable!" Seems a little misleading as setting the march=core2 or such won't enable sse without a flag such as -msse or -msse2 in the CFLAGS.....
Hmm... I initially thought that it will break somewhere when i did it.... :-/ The see useflag sets optimizations that are used elsewhere in the build. But sse itself is used anyway now. I thought I could ask gcc if it is enabled for what is defined as march in the cflags instead of writing down a list manually... But yeah, bad idea, obviously gcc doesn't enable the lower sse's automatically if sse4 is present and it's not set to native.... I just tested with march=i686 and march=native which enables all sse variants and was enough to let ardour compile here... Sooo... I guess it's best if i rename the "sse" useflag to "optimizations" first. Then make sse mandatory as Jeroen suggested. I don't know yet if it is enough to just rely on the useflag itself and ignore the cflags... I will test that and report back! Stay tuned! ;-)
Ok, its really a bug in the buildscript that doesn't treat sse right... i made a little patch for it. But I still get build failures if USE=sse and march=i686 without -msse is set! :-( Now I made a list of march-flags where no sse is enabled by default and explicitly ask for -msse. Hopefully nobody tries to use ardour with some other strange flags besides i486 and i686!? This is commited now. Thanks all!
It's still wrong. What if I set -march=pentium4 or something else you didn't think of? If the build system needs -msse /it/ (probably src_configure()) should enable that, not the ebuild - the ebuild needs to simply safeguard systems that don't have SSE instructions, using USE=sse. Why don't you simply use USE=sse like every other ebuild in the tree instead of depending on whatever ends up in someone's CFLAGS? And don't do it in pkg_pretend(), but set it up in src_configure().
(In reply to Jeroen Roovers from comment #8) > It's still wrong. What if I set -march=pentium4 or something else you didn't > think of? If the build system needs -msse /it/ (probably src_configure()) > should enable that, not the ebuild - the ebuild needs to simply safeguard > systems that don't have SSE instructions, using USE=sse. If you set -march=pentium4 gcc simply enables sse anyway (not the flag, just the ability to compile such code) and won't fail! With march=i686 gcc just does not allow you to compile such code unless -msse is set in cflags. > Why don't you simply use USE=sse like every other ebuild in the tree instead > of depending on whatever ends up in someone's CFLAGS? Because it then fails after around the half of the build... >And don't do it in > pkg_pretend(), but set it up in src_configure(). I rather adjust my make.conf before I compile anything than having an unnecessary break during an update!
(In reply to Andreas Schürch from comment #9) > (In reply to Jeroen Roovers from comment #8) > > It's still wrong. What if I set -march=pentium4 or something else you didn't > > think of? If the build system needs -msse /it/ (probably src_configure()) > > should enable that, not the ebuild - the ebuild needs to simply safeguard > > systems that don't have SSE instructions, using USE=sse. > If you set -march=pentium4 gcc simply enables sse anyway (not the flag, just > the ability to compile such code) and won't fail! With march=i686 gcc just > does not allow you to compile such code unless -msse is set in cflags. And this is why you shouldn't try to control it from pkg_pretend(). > > Why don't you simply use USE=sse like every other ebuild in the tree instead > > of depending on whatever ends up in someone's CFLAGS? > Because it then fails after around the half of the build... Yes, and then you'd have yourself to blame for setting USE=sse on a system that doesn't support it. And keep the pieces. > >And don't do it in > > pkg_pretend(), but set it up in src_configure(). This is what needs to be checked src_configure(): if have_sse || have_altivec enable_fpu_optimization endif Not this in pkg_pretend(): if have_sse && i_think_you_dont_have_sse die endif It shouldn't be hard to do.
(In reply to Jeroen Roovers from comment #10) > (In reply to Andreas Schürch from comment #9) > > (In reply to Jeroen Roovers from comment #8) > > > It's still wrong. What if I set -march=pentium4 or something else you didn't > > > think of? If the build system needs -msse /it/ (probably src_configure()) > > > should enable that, not the ebuild - the ebuild needs to simply safeguard > > > systems that don't have SSE instructions, using USE=sse. > > If you set -march=pentium4 gcc simply enables sse anyway (not the flag, just > > the ability to compile such code) and won't fail! With march=i686 gcc just > > does not allow you to compile such code unless -msse is set in cflags. > > And this is why you shouldn't try to control it from pkg_pretend(). I do not control anything, I just do sanity checks and die gently if needed. Isn't this function exactly for that purpose!? I mean it's unlikely to happen anyway, only if use take an x86 stage and do not edit the cflags. In that case the sse useflag just doesn't make any sense. Sure, I could do that check in src_config and just add -msse to the cflags to not let the build fail, but i don't like to override users choices in make.conf! > > > > Why don't you simply use USE=sse like every other ebuild in the tree instead > > > of depending on whatever ends up in someone's CFLAGS? > > Because it then fails after around the half of the build... > > Yes, and then you'd have yourself to blame for setting USE=sse on a system > that doesn't support it. And keep the pieces. Sure, we can test that and see how long it takes that someone hits that build failure and report another bug....;-) But i don't like playing games... > > >And don't do it in > > > pkg_pretend(), but set it up in src_configure(). > > This is what needs to be checked src_configure(): > > if have_sse || have_altivec > enable_fpu_optimization > endif this is in place since ever!? Don't know what you mean. > Not this in pkg_pretend(): > > if have_sse && i_think_you_dont_have_sse > die > endif If you have a better solution to check the ability to compile the stuff, then please tell me! Sure, there are maybe other marches that don't enable sse by default that are not in the list... But the chance that someone with such a lowlevel device would run ardour is quite low I guess and in that case I also don't die... Instead the build just fails after some time like you suggest it. See below for an example. And yes, there are maybe other cflags that enable gcc to buld the code - If you know them, then please tell me and i'll add them immediately! But sse and sse2 are the most common on such x86 i guess. > It shouldn't be hard to do. Yeah, I also think so... I just found that build failure on a new VM and wanted to prevent users from hitting it. Yep, the first attempt with sanity checks was bad, but letting users fail after half an hour due to known issues is just as bad imho. This happens on a fresh x86 stage with just sse enabled as use and no changes to the cflags: In file included from ../libs/ardour/sse_functions_xmm.cc:21:0: /usr/lib/gcc/i686-pc-linux-gnu/4.7.3/include/xmmintrin.h:32:3: error: #error "SSE instruction set not enabled" ../libs/ardour/sse_functions_xmm.cc: In function 'void x86_sse_find_peaks(const Sample*, ARDOUR::pframes_t, float*, float*)': ../libs/ardour/sse_functions_xmm.cc:27:2: error: '__m128' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:27:9: error: expected ';' before 'current_max' ../libs/ardour/sse_functions_xmm.cc:30:2: error: 'current_min' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:30:32: error: '_mm_set1_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:31:2: error: 'current_max' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:37:3: error: 'work' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:39:45: error: '_mm_min_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:40:45: error: '_mm_max_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:50:17: error: 'work' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:50:39: error: '_mm_load_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:51:59: error: '_mm_min_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:52:59: error: '_mm_max_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:72:3: error: 'work' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:72:25: error: '_mm_load_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:74:45: error: '_mm_min_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:75:45: error: '_mm_max_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:85:3: error: 'work' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:87:45: error: '_mm_min_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:88:45: error: '_mm_max_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:96:2: error: 'work' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:97:58: error: '_MM_SHUFFLE' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:97:59: error: '_mm_shuffle_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:98:38: error: '_mm_min_ps' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:103:24: error: '_mm_store_ss' was not declared in this scope ../libs/ardour/sse_functions_xmm.cc:107:38: error: '_mm_max_ps' was not declared in this scope * Node /var/tmp/portage/media-sound/ardour-3.5.403/work/ardour-3.5.403/build/gtk2_ardour/ardev_common_waf.sh is created by more than once (full message on 'waf -v -v'). The task generators are: 1. 'ardev_common_waf.sh' in /var/tmp/portage/media-sound/ardour-3.5.403/work/ardour-3.5.403/gtk2_ardour 2. 'ardev_common_waf.sh' in /var/tmp/portage/media-sound/ardour-3.5.403/work/ardour-3.5.403/gtk2_ardour Waf: Leaving directory `/var/tmp/portage/media-sound/ardour-3.5.403/work/ardour-3.5.403/build' Build failed
src_configure() already does this: $((use altivec || use sse) && echo "--fpu-optimization" || echo "--no-fpu-optimization") \[1] If you need CFLAGS+=" -msse" with USE=sse, then just go ahead and add it in src_configure() using append-cflags from flag-o-matic.eclass. [1] Note that the nested sub-shell isn't needed here - curly braces should be enough.
(In reply to Jeroen Roovers from comment #12) > src_configure() already does this: > > $((use altivec || use sse) && echo "--fpu-optimization" || echo > "--no-fpu-optimization") \[1] > > If you need CFLAGS+=" -msse" with USE=sse, then just go ahead and add it in > src_configure() using append-cflags from flag-o-matic.eclass. Also, you don't seem to need -msse or -msse2 at all. I see on one system that I have CFLAGS=-msse4.1 set and it compiles fine with fpu-optimization.
(In reply to Jeroen Roovers from comment #13) > Also, you don't seem to need -msse or -msse2 at all. I see on one system > that I have CFLAGS=-msse4.1 set and it compiles fine with fpu-optimization. Yeah, it just needs one of those sse flags i guess... :-) >If you need CFLAGS+=" -msse" with USE=sse, then just go ahead and add it in >src_configure() using append-cflags from flag-o-matic.eclass. Maybe you're right... If someone has sse in useflags then it is almost certain that sse is wanted! But overriding cflags is not that gentle. So the best way would probably be to check for all sse variants and add the least minimum if nothing is present. if use sse; then MARCH=$(get-flag march) for ARCHWOSSE in i686 i486; do if [[ ${MARCH} = ${ARCHWOSSE} ]]; then for SSEOPT in -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2; do is-flag ${SSEOPT} && SSEON="yes" done if [ -z ${SSEON} ]; then append-cflags -msse fi fi done fi Is that ok or did I miss something? >[1] Note that the nested sub-shell isn't needed here - curly braces should be >enough. Can you make an example? It's getting late here and you never know everything! ;-) Thanks!
Actually I don't know if there would be any difference between sse1 and say sse3 after compilation!? Maybe I should add a little elog that it might probably perform far better with just march=native after all the conditions are met and just -msse is set....
Ok, I committed that now. Have fun!
