This builds perfectly fine here w/o any fortran once the inherit is removed, confirmed by another user as well. Also the docs confirm that fortran is optional. So, forcing people to re-emerge gcc w/ USE=fortran "since configure checks for fortran" is not very nice, and also not needed. --- [ebuild R ] sys-devel/gcc-4.1.1 USE="-bootstrap -build -doc -fortran -gcj -gtk -hardened -ip28 -ip32r10k% -mudflap -multislot nls -nocxx -objc -objc++ -objc-gc -vanilla" 48 kB $ gcc-config -l [1] i686-pc-linux-gnu-3.4.4 [2] i686-pc-linux-gnu-3.4.4-hardened [3] i686-pc-linux-gnu-3.4.4-hardenednopie [4] i686-pc-linux-gnu-3.4.4-hardenednopiessp [5] i686-pc-linux-gnu-3.4.4-hardenednossp [6] i686-pc-linux-gnu-4.0.3 [7] i686-pc-linux-gnu-4.1.1 * I can attach the complete build log if needed, but don't think it's needed (also, it's huge).
Created attachment 91554 [details] fftw-3.1.2.ebuild.diff A quick patch - only check for fortran w/ USE=fortran set. Alternatively, just nuke the inherit again. :)
Hmm, strange, I had several people complaining on the forums and by mail that configure breaks when fortran is not present on their systems. If configure works for you without fortran that's great and I'll remove the inherit again. Thanks for pointing this out. Best, Markus
I apologize for the double post - the network is terrible here today and I was a little impatient :(
(In reply to comment #3) > Hmm, strange, I had several people complaining on the forums and by > mail that configure breaks when fortran is not present on their systems. Well, I guess they are victims of "eselect-compiler doesn't clean up after itself" bug :) - see Bug 135688, Bug 136363 (wrt fftw, Bug 137180 and Bug 138956 that are dupes of the former ones are relevant). Thanks!
Yeah, very possible! This eselect cleanup bug really is unpleasant. cheers, Markus
