pkg_setup() { use ifc || if [ -z `which g77` ]; then #if ifc is defined then the dep was already checked eerror "No fortran compiler found on the system!" eerror "Please add fortran to your USE flags and reemerge gcc!" die fi } can be fixed eg. by replacing it with pkg_setup() { use ifc || if [ -z `which g77` ] && [ -z `which gfortran` ]; then #if ifc is defined then the dep was already checked eerror "No fortran compiler found on the system!" eerror "Please add fortran to your USE flags and reemerge gcc!" die fi } Reproducible: Always Steps to Reproduce: 1.emerge gcc-4 && gcc-config... 2.emerge octave Actual Results: which: no g77 in (/sbin:/usr/sbin:/usr/lib/portage/bin:/bin:/usr/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.0.2:/opt/blackdown-jdk-1.4.2.02/bin:/opt/blackdown-jdk-1.4.2.02/jre/bin:/usr/qt/3/bin:/usr/kde/3.4/sbin:/usr/kde/3.4/bin) * No fortran compiler found on the system! * Please add fortran to your USE flags and reemerge gcc! Expected Results: normal compilation and funtion. Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-4.0.2, glibc-2.3.5.20050722-r0, 2.6.14-rc2-mm1 i686) ================================================================= System uname: 2.6.14-rc2-mm1 i686 mobile AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2, 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ ftp://trumpetti.atm.tut.fi/gentoo/ http://ftp.linux.ee/pub/gentoo/distfiles/ ftp://ftp.linux.ee/pub/gentoo/distfiles/ ftp://ftp.du.se/pub/os/gentoo http://ftp.du.se/pub/os/gentoo http://ds.thn.htu.se/linux/gentoo http://mirror.pudas.net/gentoo ftp://mirror.pudas.net/gentoo" LANG="en_US.UTF-8" LC_ALL="fi_FI.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/trunk /usr/local/zugaina-portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X aac acpi alsa audiofile avi bash-completion bitmap-fonts boundschecking browserplugin bzip2 bzlib c++ cdr cdrom codecs crypt curl dbcp dhcp directfb divx4linux dlloader dri dvd dvdread eds encode escreen fam fbcon firefox fortran freetype gd gif gimp glibc glut gpm gstreamer gtk gtk2 iconv imagemagick imlib ipv6 java javascript jpeg latex lcd lcms lm_sensors mikmod mime mmx motif mozilla mozsvg mp3 mpeg mpeg4 mplayer multitarget ncurses nls no-old-linux no-opts no-suexec nptl nptlonly nsplugin objc octave ogg oggvorbis opengl pam pdflib perl png print python qt quicktime readline real samba sdl sensord snmp sse ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts unicode urandom userlocales utf8 vorbis win32codecs xine xml2 xmms xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS
Hi Emil Karlson, Were you able to compile octave with gfortran? (I'm asking because you failed to mention it in the bug report). Gcc 4 is still unsupported software, however, if octave compiles and works fine with gfortran, then the patch should be applied. Thank you, Lucas Chiesa
Thanks Lucas. I have confirmed it does compile successfully with gfortran as has Lucas. Octave still seems to function fine, so I have modified the fortran compiler check in octave-2.1.71. Thanks.
Hi, unfortunately octave 2.1.71-r[12] do not compile with gcc4 anymore (due to the new fortran.class), could you re-open this bug please ?
We still have to write the new profile for gfortran in "fortran.eclass". Then we can fix this properly. For the time being, I suggest using a Portage overlay to modify the ebuild. (As gcc-4.x is still completely unsupported, this is a bit of a low priority thing.)
Kugelfang - I tried adding a gfortran profile to the fortran eclass and then adding a need_fortran g77 gfortran line to the octave ebuild. When I do that I get this error, * You need one of these Fortran Compilers: g77 gfortran * Installed are: gfortran * Current Fortran Compiler is set to g77, which is not usable with this package ! How do we handle this situation with the eclass? It should compile with gfortran if g77 is not present. I can't see how to achieve this easily but may be I am missing something.
Well, the easy solution is to just say they've gotta fix FC/F77 if it's set to something invalid in make.conf. Randomly defaulting to a different compiler is bad news, imho.
1. Gentoo-portage team doesn't care atm. 2. to install octave with gfortran remove line inherit flag-o-matic fortran from /usr/portage/sci-mathematics/octave/octave-<version>.ebuild and #ebuild /usr/portage/sci-mathematics/octave/octave-<version>.ebuild digest portage update will overrun this, but it doesn't matter, if you don't arbitarily recompile ebuilds. #emerge -av octave 3. Wait for portage team to accept gcc-4 (see 1.) 4. Portage team could add portage feature or USE flag "nocheck", since many hate portage checks anyways (including myself)
I don't think that comment #7 helps particularly, although it is clear you don't like portage-team (whoever they are). In most cases defaulting to gfortran on a GCC 4 system will work just fine and most packages compile with it successfully so I think it would be a reasonable solution to default to it where g77 isn't available. If others do not agree then we need to get this out to users in einfo/user docs. I thought that part of the point of the fortran eclass was to ease the management of fortran - if an ebuild lists fortran compilers shouldn't the first that is present on the system be used unless the user specifies otherwise? That would seem logical to me, and having g77 and gfortran as the first two seems like a good default to me. I don't view that as random, but I welcome others opinions.
(In reply to comment #8) > I don't think that comment #7 helps particularly, although it is clear you > don't like portage-team (whoever they are). In most cases defaulting to > gfortran on a GCC 4 system will work just fine and most packages compile with > it successfully so I think it would be a reasonable solution to default to it > where g77 isn't available. If others do not agree then we need to get this out > to users in einfo/user docs. I actually think we should default to gfortran even when g77 is available. > I thought that part of the point of the fortran eclass was to ease the > management of fortran - if an ebuild lists fortran compilers shouldn't the > first that is present on the system be used unless the user specifies > otherwise? That would seem logical to me, and having g77 and gfortran as the > first two seems like a good default to me. I don't view that as random, but I > welcome others opinions. Compilers should always be run through in the same order, regardless of the order in which the ebuild specifies them. IOW, fortran.eclass should specify the order of compilers to use when FC/F77 is unset. If package A says FORTRAN="g77 ifc" and package B says FORTRAN="ifc g77", I'd want them to both end up using the same compiler -- basing it on an overall preference list from fortran.eclass. Alternately, we need a way for users to specify their own preference lists instead of just a single compiler that may not work on all packages.
Should we not just use whatever tc-getF77 tells us to? It is not our place to choose a default, I think. Also, right now, the fortran eclass only checks if at least one of the appropriate compilers for the package is installed. Maybe we could extend the eclass to retreive the selected compiler using toolchain functions, then check if that compiler will work with the given package, and then make sure that it is installed. Otherwise, emerge would exit, asking the user either to select a different compiler, or to install the appropriate compiler.
(In reply to comment #10) > Should we not just use whatever tc-getF77 tells us to? It is not our place to > choose a default, I think. I don't think tc-getF77 even works right now. It looks like it checks for an f77 binary rather than g77. In addition, it only checks the F77 variable, not FC. And obviously there is no tc-getF90 yet, but that would be easy enough to add if tc-getF77 worked properly. Also, I don't think that the toolchain people will want to add the hacks to their generalized functions that we need if we want to default to gfortran on >=gcc-4, and g77 on older gcc. > Also, right now, the fortran eclass only checks if > at least one of the appropriate compilers for the package is installed. Maybe > we could extend the eclass to retreive the selected compiler using toolchain > functions, then check if that compiler will work with the given package, and > then make sure that it is installed. Otherwise, emerge would exit, asking the > user either to select a different compiler, or to install the appropriate > compiler. The eclass already defaults on its own to g77 and has its own treatment of FC and F77 variables rather than consulting tc-getF77. See the "default to g77" comment. This enhancement is a good idea and seems like a natural way for things to work. The only problem is how to integrate the eclass with the toolchain functions, as I briefly mentioned above.
>> I actually think we should default to gfortran even when g77 is available. I believe that gcc-config doesn't allow g77 and gfortran exist simultaneoysly. Forcing the use of gfortran-<gcc-version> doesn't make things any easier and reduces user's control over her own system? >> I don't think that comment #7 helps particularly, although it is clear you >> don't like portage-team (whoever they are). In most cases defaulting to >> gfortran on a GCC 4 system will work just fine and most packages compile with >> it successfully so I think it would be a reasonable solution to default to it >> where g77 isn't available. If others do not agree then we need to get this >> out to users in einfo/user docs. I like most people. I just dislike some portage policies. I still value your work for the community. Scratch #7 1. 3. I was just confused 2. might still help someone. I'll just be quiet ;)
(In reply to comment #12) > >> I actually think we should default to gfortran even when g77 is available. > > I believe that gcc-config doesn't allow g77 and gfortran exist simultaneoysly. > Forcing the use of gfortran-<gcc-version> doesn't make things any easier and > reduces user's control over her own system? My system begs to differ. $ gfortran gfortran gfortran-4.1.0-beta20051202 gfortran-4.0.2 $ which g77-3.4.4 /usr/bin/g77-3.4.4
I haven't forgotten about this, please take a look at bug 65950 where I have proposed a patch to the current eclass to automatically select gfortran when it is available. Donnie I think this approach could be extended to introduce a default priority order too. I welcome comments - it allowed me to compile dev-lang/R-2.2.1 on my GCC 4.0 system using gfortran, and using g77 on my GCC 3.4 system. If there are no objections I will commit the patch.
(In reply to comment #14) > I haven't forgotten about this, please take a look at bug 65950 where I have > proposed a patch to the current eclass to automatically select gfortran when it > is available. Donnie I think this approach could be extended to introduce a > default priority order too. If it works, go for it. I don't really have time to deal with this in detail right now, as I've got about a thousand other things on my plate and I trust you'll do things sanely.
Right - I have committed the updated fortran.eclass. Please sync in about an hour and octave should compile with gfortran out of the box on GCC 4 systems. Hopefully this one will stay fixed now :)
*** Bug 129857 has been marked as a duplicate of this bug. ***
