The current stable version fails to build with GCC 4.7. Thanks.
Version 3.3.3-r2 looks good to me. Targets: alpha amd64 arm hppa ia64 mips ppc ppc64 sparc x86 @sci: Please speak up in the next week, otherwise I will add archs.
(In reply to Christoph Junghans from comment #1) > Version 3.3.3-r2 looks good to me. Maybe -r1 and -r2 would need to wait for stabilization of some multilib stuff (looks like it is blocking the sets but I see no new dep)
(In reply to Pacho Ramos from comment #2) > (In reply to Christoph Junghans from comment #1) > > Version 3.3.3-r2 looks good to me. > > Maybe -r1 and -r2 would need to wait for stabilization of some multilib > stuff (looks like it is blocking the sets but I see no new dep) I think fftw-3.3.3-r2 is fine, the only lib dependency is virtual/mpi, but it is questionable if this will become multilib soon or ever. However I would maybe rework REQUIRED_USE="amd64? ( abi_x86_32? ( !mpi !quad ) )" into disabling mpi and quad inside src_configure for abi_x86_32 on amd64, so that mpi and quad can be enabled together with abi_x86_32 as e.g. sci-physics/mpb needs fftw[mpi].
As soon as this DEPEND is present: abi_x86_32? ( !<=app-emulation/emul-linux-x86-soundlibs-20130224-r2 !app-emulation/emul-linux-x86-soundlibs[-abi_x86_32(-)] )" I don't think it can go to stable without either we stabilizing newer emul set revisions (that will need to also stabilize many more packages) or use.masking the USE flag in stable profiles :/
(In reply to Pacho Ramos from comment #4) I won't have time to contribute much for at least 1 month; so, unless someone wants to relay me in "agressively converting packages to multilib eclasses", I think it'd be a good time to stabilize what we have atm by: - stabilizing packages one by one and package.stable.use.mask'ing abi_x86_32 for them - once all are done, at least on amd64, stabilize latest revisions of emul-libs and remove the use.masks
# Pacho Ramos <pacho@gentoo.org> (07 Sep 2013) # It requires newer emul sets to be stabilized (#477182#c5) ~sci-libs/fftw-3.3.3 abi_x86_32 Should be ready to CC arches now
I added fftw-3.3.3-r3 to science overlay for testing, this one comes without REQUIRED_USE, but has other problems (<https://github.com/FFTW/fftw3/pull/6> and especially #483758), so fftw-3.3.3-r2 is a better stable candidate. What was the reason to block quad on abi_x86_32 in the first place? It builds fine on my Core i7.
I don't know, but this is what ChangeLog has related with this: *fftw-3.3.3-r2 (10 Mar 2013) 10 Mar 2013; Justin Lecher <jlec@gentoo.org> fftw-3.3.3-r1.ebuild, +fftw-3.3.3-r2.ebuild: Multibuild for the precision builds, thanks mgorny to prepare the patch; restrict USE=quad for x86 as there are to less registers Looks like quad won't work ok for x86 building then :/
(In reply to Christoph Junghans from comment #7) > I added fftw-3.3.3-r3 to science overlay for testing, this one comes without > REQUIRED_USE, but has other problems (<https://github.com/FFTW/fftw3/pull/6> > and especially #483758), so fftw-3.3.3-r2 is a better stable candidate. > > What was the reason to block quad on abi_x86_32 in the first place? It > builds fine on my Core i7. If you run the tests, you'll notice that quad on x86 simply fails :). I don't remember the exact kind of error though, SIGILL, SIGSEGV or something like that.
(In reply to Michał Górny from comment #9) > (In reply to Christoph Junghans from comment #7) > > What was the reason to block quad on abi_x86_32 in the first place? It > > builds fine on my Core i7. > > If you run the tests, you'll notice that quad on x86 simply fails :). I > don't remember the exact kind of error though, SIGILL, SIGSEGV or something > like that. I see, shouldn't quad be masked on x86 then?
Yes, it should. Unless there's some other thing I don't recall now :).
(In reply to Michał Górny from comment #9) > (In reply to Christoph Junghans from comment #7) > > I added fftw-3.3.3-r3 to science overlay for testing, this one comes without > > REQUIRED_USE, but has other problems (<https://github.com/FFTW/fftw3/pull/6> > > and especially #483758), so fftw-3.3.3-r2 is a better stable candidate. > > > > What was the reason to block quad on abi_x86_32 in the first place? It > > builds fine on my Core i7. > > If you run the tests, you'll notice that quad on x86 simply fails :). I > don't remember the exact kind of error though, SIGILL, SIGSEGV or something > like that. I can confirm that problem on my Intel Atom 330, the test fails for quad with "received signal 11". That of course leads to the question why gcc installs libquadmath.so on x86.
(In reply to Christoph Junghans from comment #12) [...] > I can confirm that problem on my Intel Atom 330, the test fails for quad > with "received signal 11". That of course leads to the question why gcc > installs libquadmath.so on x86. Will CC gcc maintainers for that then
(In reply to Michał Górny from comment #11) > Yes, it should. Unless there's some other thing I don't recall now :). + 08 Sep 2013; Christoph Junghans <ottxor@gentoo.org> package.use.mask: + masked sci-libs/fftw[quad] +
I guess, arches can be CCed then?
Yes, target keywords: alpha amd64 arm hppa ia64 ppc64 ppc sparc x86
Stable for HPPA.
amd64 stable
x86 stable
ia64 stable
alpha stable
ppc64 stable
sparc stable
ppc stable
arm stable. Last arch, closing
