This is not necessarily a "bug" in gentoo as it is an issue that needs to be addressed. When using GCC 4.0+ as the system compiler, many Fortran-dependent packages do not compile, since their configurations do not yet support the new gfortran compiler (which replaced GCC). Among the packages affected: sci-libs/blas-atlas sci-libs/lapack-atlas sci-chemistry/mpqc sci-mathematics/euler
I've got patches for blas-atlas and lapack-atlas, but I haven't committed them yet.
I'll have a look at mpqc. I am pretty sure that sci-chemistry/gamess will also have problems, and I have some patches that might fix this, but simply haven't had the time to test them yet. Thanks, Markus
(In reply to comment #0) > Among the packages affected: > > sci-chemistry/mpqc mpqc compiles and works fine for me using gcc-4.0.2-r3. Could you please post your error message. Thanks, Markus
Wouldn't mind some testing on my blas-atlas and lapack-atlas changes ... http://dev.gentoo.org/~spyderous/overlay/sci-libs/
(In reply to comment #4) > Wouldn't mind some testing on my blas-atlas and lapack-atlas changes ... > http://dev.gentoo.org/~spyderous/overlay/sci-libs/ > Both compile fine for me! The only thing I noticed was that instead of completely removing the compiler check in the allow-any-gcc-version.patch one could also just add gcc-4.x to the list of allowed ones. Then again, considering the gcc versions available in portage the check doesn't do anything anyway.
(In reply to comment #0) > sci-mathematics/euler Ok, I had a go at euler-1.61.0 and the main problem isn't gfortran, but rather an invalid declaration in one of the C files. Also, it seems that at least on my setup the supplied configure completely ignores the supplied CFLAGS. I think I've fixed it all and it compiles and runs fine for me. I'll attach the patches below; if somebody could give them a try that would be great. Thanks, Markus
Created attachment 79289 [details, diff] patch taking care of bad configure and gfortran invocation
Created attachment 79290 [details, diff] patch for autotool files
Created attachment 79291 [details, diff] patch to fix invalid declaration in C file
Created attachment 79343 [details, diff] updated patch for ebuild using autotools.eclass
sci-mathematics/octave also needs to be added to the list
The following two packages should now work properly with gfortran/gcc-4.x sci-mathematics/euler sci-chemistry/gamess
(In reply to comment #11) > sci-mathematics/octave also needs to be added to the list > sci-mathematics/octave-2.1.72 compiles fine here with gcc-4.0.2-r3. Could you please give some more details regarding your compile failure? Thanks, Markus
One thing worth noting is that applications can compile with the gcc-4.1 gfortran and fail with the gcc-4.0 gfortran, so if you test with 4.1, make sure you also test with 4.0.
(In reply to comment #14) > One thing worth noting is that applications can compile with the gcc-4.1 > gfortran and fail with the gcc-4.0 gfortran, so if you test with 4.1, make sure > you also test with 4.0. > Thanks for pointing that out - I am currently testing with gcc-4.0.2 only!
*** Bug 125205 has been marked as a duplicate of this bug. ***
*** Bug 125682 has been marked as a duplicate of this bug. ***
scilab missing, i opened a specific bug for that some days ago
*** Bug 126710 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Wouldn't mind some testing on my blas-atlas and lapack-atlas changes ... > http://dev.gentoo.org/~spyderous/overlay/sci-libs/ > No problems to report with gcc-4.1 on a P4. Thanks!
Committed blas-atlas and lapack-atlas fixes.
(In reply to comment #5) > (In reply to comment #4) > > Wouldn't mind some testing on my blas-atlas and lapack-atlas changes ... > > http://dev.gentoo.org/~spyderous/overlay/sci-libs/ > > > Both compile fine for me! > The only thing I noticed was that instead of completely removing the > compiler check in the allow-any-gcc-version.patch one could also just > add gcc-4.x to the list of allowed ones. Then again, considering the gcc > versions available in portage the check doesn't do anything anyway. Yeah, the reason I didn't do that is so it's scalable to future gcc versions as well. I'd rather be able to completely forget about that patch instead of touching it even once a year or whatever.
*** Bug 134880 has been marked as a duplicate of this bug. ***
If there are any remaining applications in this bug, please open individual bugs for them.
