Just a request to update FFTW to the new and improved version 3.0 that was recently released at http://www.fftw.org Reproducible: Always Steps to Reproduce: 1. 2. 3.
Hi BS. Just a qiuck note, that I noticed this and looking at the upgdare right now. Its not quite straightforward though - 3.0 is not API compatible with earlier versions. I need to check if it can peacefully coexist with 2.x ones or some stuff will have to be moved around. Any remarks/experience in dealing with new version are appreciated. Also, 3.0 does not yet support mpi, which is required (optionally) by some packages in portage. Well, it yet remains to be seen if these packages can be cmpiled against new version at all actually.. So, it's gonna take some time.. George
Ya, its not API compatiable. All the reasons are discussed in the FAQ at the FFTW site - I guess you saw those. There's also an upgrade guide which is straight forward. I doubt that many programs written for 2 will work with 3. However, it seems that 3 is far superior in many respects. I'm not sure what the best way to deal with the upgrade - probably in seperate slots. Thanks George. I'll post if anything interesting comes up. BS
debian uses fftw3 as a new package name. swh-plugins now supprts building against fftw3 . i would vote for a new package name because fixing all packages which depend on fftw2 would be too much work ithink.
Created attachment 12657 [details] ebuild using fftw3 as package name just in case you want to use fftw3 for package name. There are some configure options which should be set. and a different tar file for powerpc. but this one here already compiles...
Hi Torben, BS. Sorry I am a bit behind on this one - fftw-3 is not yet really ready to replace fftw-2 in every situation, particularly mpi is not supported yet, so this one was lagging a bit :(. Anyway with the ebuild submitted now I should get to it shortly - within a few days. The biggest issue is to make sure that fftw-3 and fftw-2 can be installed side-by-side and not overwrite any important files of another one.. Missing that is really a bad thing, as some people might want to use advansed features of fftw-3 but will still need to keep fftw-2 around. On the other hand, having done this separation it really doesn't make sense to create another package dir and rename a package because of the change, just stamp new SLOT on it - this is why we introduced SLOTs after all! >debian uses fftw3 as a new package name. Well,they are binry distro, so they have different issues with naming and I think they cannot do what we can with SLOTs. As for amount of work - I don't think there are more than 10 ebuilds in the tree that would need >=fftw-2 replaced by =fftw-2*, this is not such a big deal and can even be scripted pretty easily should there be a need. I'll help you out in that. Ok, I'll take a look at this ebuild shortly, so more comments will be coming, but I wanted to comment on the naming issue, as it is independent of what I will see in ebuild. George
Created attachment 13483 [details] fftw ebuild for 3.0, using slot '3.0' and no MPI very simple forward port of the 2.1.5 ebuild. none of the new configure options have been investigated. MPI is disabled as this is not supported in 3.0, yet.
oh, read the history after submitting the patch. anyway, it looks to me as if FFTW 2 and 3 can coexist peacefully. Headers and libraries have, for the most part, different names. I'm not sure about 'dfftw.h' but it looks fine.
Created attachment 15050 [details] Another ebuild for fftw-3.0.1 Was looking at installing fftw-3.0.1 and found this enhancement request ... I've attached an ebuild which seems to work and doesn't clobber fftw-2.x; it applies --enable-sse, --enable-sse2 and --enable-3dnow as according to use variables. With gcc 3.2.3 and -march=pentium3, -O3 and sse (or sse2) will produce bad code. The current ebuild has been confirmed to work with gcc 3.2.3, -march=pentium3 and -march=pentium4 with --enable-sse and --enable-sse2 with the -O2 optimization flag forced. (At least it was fine according to make check.) Given the sensitivity on CFLAGS, perhaps a strip-flags is in order? I'm guessing it really needs to be tested on other architectures/cpus too.
Hi guys. Thanks for the ebuilds! And sorry for the delay. Looks like bugzila again tried to save on notification emails :(, just got here on a regular sweep. Anyway, I processed ebuilds, did few cleanups (most notably: function filter-mfpmath has been added to flag-o-matic.eclass and it now should be used for filtering of this one) and committed. Please test. George
reclosing the bug
