Bugzilla Bug 121855

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 an attachment (id=79289) [edit]
patch taking care of bad configure and gfortran invocation

Created an attachment (id=79290) [edit]
patch for autotool files

Created an attachment (id=79291) [edit]
patch to fix invalid declaration in C file

Created an attachment (id=79343) [edit]
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.