| 1 |
>> |
| 2 |
>> justin |
| 3 |
>> |
| 4 |
> |
| 5 |
> That make sense? |
| 6 |
> |
| 7 |
> Dale |
| 8 |
> |
| 9 |
> :-) :-) |
| 10 |
> |
| 11 |
|
| 12 |
Hi, |
| 13 |
|
| 14 |
as most of you do not like to have fortran enabled by default, we tried |
| 15 |
to find a way around. We created a virtual/fortran which should depend |
| 16 |
on a working fortran compiler so that only ebuilds which need fortran |
| 17 |
compiler will build it. With that situation it was possible to remove |
| 18 |
USE=fortran from the profile (btw profiles cannot have a version bump |
| 19 |
and don't need it) so that most of you could drop the fortran support |
| 20 |
from gcc except a ebuild depends on it. |
| 21 |
|
| 22 |
However I wasn't aware that there is no hierarchy in the dependencies in |
| 23 |
an ebuild and portage will choose a solution w/o a USE change first. |
| 24 |
That is the reason why many of you saw that ifc should be installed, |
| 25 |
instead of gcc with USE=fortran. That was the point where I added it |
| 26 |
back to the profile as a default enabled USE. |
| 27 |
|
| 28 |
The solution for the average user is leaving all default USE on. This |
| 29 |
will gcc build the fortran support and you will have no problem. (Libs |
| 30 |
and compiler are 1.5MB on my system) |
| 31 |
|
| 32 |
Or remove add -fortran to your make.conf and add sys-devel/gcc fortran |
| 33 |
to your /etc/portage/package.use. |
| 34 |
|
| 35 |
Trying to avoid any fortran at all is stupid, because as already |
| 36 |
mentioned many math operations are faster if programmed in fortran. |
| 37 |
|
| 38 |
Cheers justin |
Archives