Many scientific computing users have codes written in Fortran 90 or newer. The fortran version built by Portage when the fortran USE flag is specified is g77 (Fortran 77). This is the only fortran compiler supported by the GCC 3.4 tree. The G95 project ( http://g95.sourceforge.net/ ) has a GCC-4 based free stand-alone Fortran 95 compiler which is used commonly in the scientific computing community. It would be very valuable for such users to have an ebuild for g95 within the Portage system. Reproducible: Always Steps to Reproduce: 1. 2. 3.
*** Bug 102206 has been marked as a duplicate of this bug. ***
Created attachment 88753 [details] Ebuild for g95 Finally my attempt on g95 ebuild seems to work. Requires a patch that I'm going to submit next. Beware version numbers -- they are absent from the source archive name and sip(le-minded)ly hardcoded into both my ebuild and the patch.
Created attachment 88754 [details, diff] Patch to build g95 Corrects $(DESTDIR) usage in the makefiles for the ebuild to install (hopefully) correctly (into /usr/local -- I'm sorry I've forgotten to say that when submitting the ebuild).
Created attachment 92377 [details] g95-0.90.ebuild Updated ebuild for g95. Slightly improved structure, adapted to the 0.90 version. Note that the source tarball at g95.org is constantly called g95_source.tgz, although regularly updated. The ebuild should now handle version changes, but portage won't download new sources anyway, if there is any version in ${DISTDIR}, renaming the ebuild won't help, of coarse, when the source tarball is not being renamed. Also if you download the up to date version of g95_source.tgz, you will have to regenerate the ebuild digest. The ebuild uses a patch for the Makefile to install correctly within the portage frame; the patch must have the same version number as the ebuild, and should work for all the versions of g95, until its Makefile changes significantly: At least from 0.50 to 0.90 version the patch and its handling within the ebuild were only changed not to depend on the version stated in the name of the unpacked sources directory. g95 depends on gcc 4, and is guaranteed to work with 4.0.3 version. The ebuild performs its light compilation on its own, just according to the instructions of g95.org. Newer gcc versions have not been tested yet with g95-0.90, while with g95-0.50 gcc-4.1.1 did not work. All the files are installed into /usr/local tree, not to mess up with the gcc installation in /usr.
Created attachment 92378 [details, diff] g95-0.90-destdir.patch Patch for g95 to perform correct installation within the portage frame. Updated from 0.50 version not to depend on the g95 version number.
Created attachment 93670 [details] Version 0.9 ebuild There is now a "stable" 0.9 release, so I've attempted to modify the ebuild in the light of this. Currently it seems to be ignoring my request to only compile the C bit of GCC when it does the gcc build - I was getting GCJ libraries when I killed it.
Created attachment 93733 [details] A better g95-0.9 ebuild This one should work properly. Still quite slow because we have to build gcc, but works. I've removed the /usr/local installation prefix so it uses default in /usr, and fixed it so that your GCC installation doesn't get clobbered. You may find it doesn't work if your normal GCC version is different to the one used by the ebuild (currently GCC 4.1.1) because the right directories aren't in the PATH / LIBPATH.
Created attachment 96955 [details] Different g95-0.90-r2.ebuild, installed on amd64 I've got stuck with g95 compilation on my amd64 box for some time. Not paying proper attention to this bug, and thus modifying only my own previous ebuilds (sticking to /usr/local prefix), I finally succeded in dealing with multilib after incorporating part of the stuff used for building gcc. g95.eclass contains several slightly mangled functions from toolchain.eclass; since the original functions do not provide for changes in compilation directories layout, and g95 relies on its particular queer way to place them, simple reuse of the standard eclass was not possible. I'm affraid it's a quick and dirty hack, but it seems to work at least. g95-0.90-destdir.patch was accompanied by g95-0.90-libdir.patch fixing problems that I've experienced on amd64 with my compiled g95 built-in library lookup. Advancing from gcc-4.0.3 to gcc-4.1.1 still does'nt work.
Created attachment 96956 [details, diff] g95-0.90-libdir.patch
Created attachment 96957 [details] eclass/g95.eclass
*** Bug 156036 has been marked as a duplicate of this bug. ***
This bug had been dead for quite some time. Is there any plan to add g95 in portage soon?
(In reply to comment #12) > This bug had been dead for quite some time. Is there any plan to add g95 in > portage soon? > there no need to do it since gfortran (part of gcc since 4.x) works fine with Fortran 95 and fortran 2003
Definitely obsolete.
I have been using G95 for several years on Ubuntu as a generation target language for a "FortranCalculus2" modeling language translator, a 5GL successor to the PROSE modeling language 4GL (Wikipedia), from the time-sharing mainframe era. I have had difficulties with gfortran, and I must have a free F95 to distribute FC2 as open-source. FortranCalculus2 is a (very-high-level) end-user-development DIY-RAD language implemented with overloaded and nestable automatic-differentiation arithmetic, and an API of simulation and optimization solvers (a "MetaCalculus paradigm engine", implementing Simon's famous parable of two watchmakers, which gave rise to Koestler's "Holon" concept. I am planning to release it to the open-source community and distribute refactoring webinars. It will also be used to create very-very-high-level (6GL) modeling languages with Python and Perl grammars, and GUI composers for optimization modeling (7GL) to capitalize on the enormous end-user development market, now realized to be 20 times the size of the professional programming market. As these are "Metaphoric languages". Our intent is to use Gentoo to produce a "Metaphoric Linux" distro using the Trinity Desktop Environment (KDE 3.5 fork), flavored for end-users. Its Man documentation content will be menu driven "KindMan" to vastly simplify the CLI interface. We believe Metaphoric Linux will become the largest Linus distro in the near future. Please reinstate the G95 ebuild. It is now g95-0.94, so it is still popular. Thank you, Joseph Thames
What is the problem with gfortran? And does flang work?
(In reply to Christoph Junghans from comment #16) > What is the problem with gfortran? And does flang work? I don't know if there is one with gfortran now. I have not tried it in several years on Ubuntu. I moved to G95 because it was not impacted by the flux of changes to the whole GNU compiler collection. I don't know anything about flang. What is it?
