Building gfortran-7.0.0 under the Windows 10 bash shell

[paul.rich...@gmail.com]

Dear All,

Windows 10 now delivers with the Windows Subsystem for Linux (WSL). Under WSL ubuntu 14.04 and the bash shell can be activated. There are plenty of instructions out there on how to do this but it is quite simple: just turn on developer mode: https://msdn.microsoft.com/windows/uwp/get-started/enable-your-device-for-development, followed by opening the Windows command prompt and typing "bash". This latter starts the process of downloading bash and Ubuntu.

Unfortunately, the version of gcc is rather ancient, 4.8.4, so I set about building gcc 7.0.0 from the Christmas Day snapshot....

m4, flex, make and g++ are all missing and so must be installed before anything else using
sudo apt-get install m4 and so on.

Then gmp, mpfr and mpc must be built. The websites can be found by searching for "gnu gmp" etc.. Downloading the .tar.bz2 (tar.gz for mpc) versions of the sources, they can be unpacked using:

tar -xjf /mnt/c/Users/User/Downloads/gmp-6.1.2.tar.bz2
followed by
cd gmp-6.1.2
./configure
make
sudo make install
cd ..

will build and install gmp. The same procedure is followed for mpfr and mpc, excepting that for the latter the tar options are -xzf.

Now gcc can be built:
mkdir gcc
cd gcc
tar -xjf /mnt/c/Users/User/Downloads/gcc-7-20161225.tar.bz2
mkdir build
cd build
../gcc-7-20161225/configure --prefix=/irun --disable-multilib --enable-languages=c,fortran --disable-bootstrap

The prefix 'irun' is arbitrary - I use it for historical reasons
You get g++ as well as gcc.
--disable-bootstrap can be discarded if you have the patience!

Note the path to the Windows C drive - /mnt/c

make
sudo make install

should after a little while produce you a functioning version of gfortran-7.0.0
To check all is well, try one of the testsuite testcases

cd ~ to get yourself in the top of your workspace
/irun/bin/gfortran --static-libgfortran ~/gcc/gcc-7-20161225/gcc/testsuite/gfortran.dg/submodule_1.f08
./a.out

Will run the testcase. Look for the *.smod files to check all is well. If there is anything wrong in runtime, it will abort.

submodule_4.f08 tests for a number of errors and so is quite verbose at the terminal.

Similarly dtio_1.f90 etc. will check the functioning of User Defined Derived-Type IO.

If you have a go at this, please contact me directly with any problems or improvements. Rather than polluting the list, I will put together a compendium of gotchas and improvements in a few weeks time.

Happy New Year to one and all

Paul

[Tim Prince]

I didn't need disable-bootstrap; it seems better to go through bootstrap
to be more sure of things.
The requirement for --disable-multilib is associated with the
non-support of 32-bit mode in WSL. Also, the scheme for libraries seems
to be somewhat like standard linux, with /lib64 and the like, rather
than following older Ubuntu practice. There is no WSL for 32-bit Windows.
gmp, mpfr, mpc from apt-get appear to be less troublesome than building
those from source. I followed the standard gcc advice about which of
these will be required. In some cases, it's necessary to look up their
Ubuntu names.

Until recently, most updates of gcc/gfortran trunk were able to complete
testsuite (if run as single threads, including the possibility of
running make -k check-c and check-fortran in separate shells). This
requires installing the offered dejagnu and expect. make -k check-c++
has been failing from the beginning of Win10 "anniversary." It hangs the
the entire WSL, as did gcc and gfortran testsuites on my most recent
attempt.
I missed editing in the WSL designation in some of my gcc testsuite
reports (by default the reports show as linux). It seems clear that
more cases fail on WSL than on generally reported linux distros.
Will supporting gfortran on WSL become a priority to the extent that the
testsuite may be useful?
Does this mean gfortran 6.3 will be the last version to be supported
directly on Windows? Windows 10 conversion wasn't entirely successful
on this win8.1 installation so I'm running it only on my old Nehalem
desktop.

[Damian Rouson]

Just so people are aware, this process is likely to take the better part of a day if my experience is representative. Hopefully many people will find it easiest to use the OpenCoarrays installer to install gfortran and OpenCoarrays is required for accessing the parallel features of Fortran 2008 and 2015. I started the process of writing a skeletal bash script to describe the necessary steps to build OpenCoarrays on gfortran in OpenCoarrays Issue 227:

https://github.com/sourceryinstitute/opencoarrays/issues/227

Currently, the script builds gfortran, but fails on building MPICH, which is the default communication layer for supporting the parallel features. In fact, I get the same error whether attempting to build MPICH or OpenMPI:

mpich-3.2/confdb/missing: line 81: aclocal-1.15: command not found
WARNING: 'aclocal-1.15' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
<http://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<http://www.gnu.org/software/autoconf>
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
make: *** [/home/rouson/Desktop-shortcut/opencoarrays/prerequisites/downloads/mpich-3.2/aclocal.m4] Error 127

Prior to configuring, I installed aclocal installed via “sudo apt-get install automake,” which provided aclocal-1.14. I attempted unsuccessfully to build aclocal-1.15, but the discussion at the following URL suggests that the problem might relate to time stamps on file MPICH tar ball:

http://stackoverflow.com/questions/18769770/user-of-autotools-generated-tarball-gets-error-message-aclocal-1-13-command-no

I tried several of the steps suggested at the above link, but each leads to the following error message during the make step:

$ make
( cd ./src/binding/fortran/mpif_h && ./buildiface )
Replacing mpif.h.in
( cd ./src/binding/fortran/use_mpi && ./buildiface )
Replacing mpi_base.f90.in
Replacing mpi_constants.f90.in
Replacing mpi_t1.f90
( cd . && rm -f .err unusederr.txt ; rm -rf .tmp )
( cd . && \
./maint/extracterrmsgs -careful=unusederr.txt \
-skip=src/util/multichannel/mpi.c \
`cat maint/errmsgdirs` > .tmp 2>.err )
( cd . && if test -s .err ; then rm -f .tmp ; cat .err ; exit 1 ; fi )
Warning: attempt to redefine **fail. Duplicate ignored.
make: *** [src/mpi/errhan/defmsg.h] Error 1


Damian

[FX]

> Unfortunately, the version of gcc is rather ancient, 4.8.4, so I set
> about building gcc 7.0.0 from the Christmas Day snapshot....

Out of curiosity, what's the target triplet for that setup?

--
FX

[Tim Prince]

x86_64-pc-linux-gnu is the one quoted in test results report
No, WSL build doesn't take more than a fraction of the time of a native
Windows build.

[cyrmag7]

You can also install Gfortran (GNU Fortran (Ubuntu 6.2.0-3ubuntu11~14.04) 6.2.0 20160901) using the standard Ubuntu command "sudo apt-get..." in WSL, unless you insist on building Gfortran yourself.

[Tim Prince]

askubuntu advises using command 'sudo apt-get install gfortran' as
giving the latest available version, which, as others mentioned, is 4.8.4.

[Ian D Chivers]

I'll include a news item on this in the April edition of Fortran Forum.
Just followed the instructions and successfully compiled and ran
a simple mpi example.

program ch3001
use mpi
implicit none
integer :: error_number
integer :: this_process_number
integer :: number_of_processes

call mpi_init(error_number)
call mpi_comm_size(mpi_comm_world, &
number_of_processes, error_number)
call mpi_comm_rank(mpi_comm_world, &
this_process_number, error_number)
print *, ' Hello from process ', &
this_process_number, ' of ', &
number_of_processes, 'processes!'
call mpi_finalize(error_number)
end program ch3001

Good news.

[cyrmag7]

The way they have things set up, you have to use 'sudo apt-get install gfortran-6' .

[grazios...@gmail.com]

Il giorno giovedì 29 dicembre 2016 19:51:28 UTC+1, paul.rich...@gmail.com ha scritto:
> Dear All,

>
> Unfortunately, the version of gcc is rather ancient, 4.8.4, so I set about building gcc 7.0.0 from the Christmas Day snapshot....

I have built the same snapshot installing the needed packages (gmp, flex etc.) with apt-get:

../gcc-7-20161225/configure --prefix=/opt/gcc7 --disable-multilib \
--enable-languages=c,c++,fortran

make -j3

(about 6 hours! AMD Athlon X2). Now my question is how correctly install and use this build. Shouldn't we set a few environment variables (LIBRARYPATH and friends)?

I think there is the risk to build a program with gcc7 but using the GCC libraries of the installed 4.8 compiler.

So...

> I will put together a compendium of gotchas and improvements in a few weeks time.

please, add to the compendium what exactly one has to do to avoid that risk. Maybe a script, thisgcc.sh, to be sourced, is sufficient..

Thanks,
Angelo.

Happy New Year!

[Tim Prince]

On 12/30/2016 11:47 AM, grazios...@gmail.com wrote:
> Il giorno giovedì 29 dicembre 2016 19:51:28 UTC+1, paul.rich...@gmail.com ha scritto:
>> Dear All,
>>
>> Unfortunately, the version of gcc is rather ancient, 4.8.4, so I set about building gcc 7.0.0 from the Christmas Day snapshot....
>
> I have built the same snapshot installing the needed packages (gmp, flex etc.) with apt-get:
>
> ../gcc-7-20161225/configure --prefix=/opt/gcc7 --disable-multilib \
> --enable-languages=c,c++,fortran
>
> make -j3
>
> (about 6 hours! AMD Athlon X2). Now my question is how correctly install and use this build. Shouldn't we set a few environment variables (LIBRARYPATH and friends)?
>
> I think there is the risk to build a program with gcc7 but using the GCC libraries of the installed 4.8 compiler.
>
> So...
>

You have no option other than to build the companion gcc7 and have it on
PATH and LD_LIBRARY_PATH, so using the companion gcclib. The configure
scripts adapt to the installed versions of glibc as well as the other
supporting packages.
If you could find an apt-get repository offering gcc-6, you could avoid
the minor issue of the bootstrap-compiler not supporting -fno-PIE.

As with any installation of gfortran, you simply prepend your
installation path to PATH and LD_LIBRARY_PATH. I find that
--prefix=/usr/local/gcc7 results in the library directory
/usr/local/gcc7/lib64 (as it would with standard linux x86_64). If you
wish to over-write the compilers installed by apt-get, you would use
--prefix=/usr/; then you would not need to set PATH and LD_LIBRARY_PATH.
You would need to have rebuilt successfully every one of the gnu
compilers you will use before running make install (and any future
apt-get run has the chance of over-writing your new installation).

I find today that the gcc trunk svn server is locked up, so I have no
chance to see if the recent problem of gfortran not completing testsuite
may have been fixed.

[grazios...@gmail.com]

Il giorno venerdì 30 dicembre 2016 18:50:45 UTC+1, Tim Prince ha scritto:
> You have no option other than to build the companion gcc7 and have it on
> PATH and LD_LIBRARY_PATH, so using the companion gcclib.

I did this:

export PATH="/opt/gcc7/bin:$PATH"
export LD_LIBRARY_PATH="/opt/gcc7/lib64:$LD_LIBRARY_PATH"

and rebuild one of my programs:

rm -rf {*.mod,~/programming/modules/*} && gfortran -O3 -march=native -funroll-loops -Wall -Wno-unused-dummy-argument -
J ~/programming/modules ~/programming/basic-modules/{kind,math}_consts.f90 ~/programming/ode-modules/{everhart_integrato
r,cernlib_integrators}.f90 test_jsunp.f90 -o test_jsunp && rm -rf {*.mod,~/programming/modules/*}

and

ldd test_jsunp
linux-vdso.so.1 => (0x00007fffd3214000)
libgfortran.so.4 => /opt/gcc7/lib64/libgfortran.so.4 (0x00007f2f5e060000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2f5dd50000)
libgcc_s.so.1 => /opt/gcc7/lib64/libgcc_s.so.1 (0x00007f2f5db20000)
libquadmath.so.0 => /opt/gcc7/lib64/libquadmath.so.0 (0x00007f2f5d8e0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2f5d510000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2f5e600000)

This looks fine to me! Isn't it? (BTW, test_jsunp works as expected)

Ciao,
Angelo.

[Damian Rouson]

On Friday, December 30, 2016 at 11:23:11 AM UTC-5, Ian D Chivers wrote:
>
> I'll include a news item on this in the April edition of Fortran Forum.

Does "this" refer to a news item about building GCC 7 from source in the Windows 10 Ubuntu Linux subsystem?

> Just followed the instructions and successfully compiled and ran
> a simple mpi example.

I don't think MPI was mentioned in the original post. What MPI implementation did you use and what were your steps to build it? Did you build it with GCC 7 or with an earlier GCC?

Damian

[Ian D Chivers]

On 31/12/2016 00:35, Damian Rouson wrote:
> On Friday, December 30, 2016 at 11:23:11 AM UTC-5, Ian D Chivers wrote:
>>
>> I'll include a news item on this in the April edition of Fortran Forum.
>
> Does "this" refer to a news item about building GCC 7 from source in the Windows 10 Ubuntu Linux subsystem?

I normally add details about the latest versions of gfortran, using the
information on the gfortran site in the news section of Fortran Forum,
as this changes fairly frequently.

I'll also add details of using gfortran on Windows using the
Windows 10 windows subsystem for linux option. This may be
an attractive option for some people.

I was not going to add details about building gcc 7 from scratch
in the April edition.

Would you like to see something about what you and Paul are doing in the
coarrays area in a future edition of Fortran Forum?

I'm always looking for copy!

>
>> Just followed the instructions and successfully compiled and ran
>> a simple mpi example.
>
> I don't think MPI was mentioned in the original post. What MPI implementation did you use and what were your steps to build it? Did you build it with GCC 7 or with an earlier GCC?

The MPI versions Jane and I use depend on the people attending the
courses. We don't cover building MPI but on its use.

In the UK for people with research grants from the various research
councils we introduce them to the Cray service at Edinburgh
as in most cases they get automatic free access to this system. They
just have to apply for an account.

They also get access to the Cray compiler and coarrays
on this system.

A signficant number of people use the Intel compiler so we cover
the use of the Intel MPI library. They also have access to the
Intel coarray implementation.

Half of our teaching is done using Windows.
On these systems we normally install cygwin
and the complete gnu compiler collection
and openmpi.

The other half is done using Linux.
We started by using Redhat and Suse linux
in the late 1990s.

We currently use the opensuse distribution,
gnu compiler collection, and openmpi.

For commercial users who want to try out
coarrays and don't use the Intel compiler we normally recommend that
they get commercial accounts on the Cray systems
at Edinburgh.

For small scale work this is generally cheaper
than a full blown Intel licence.

Most of the people on the courses are scientists and engineers
and they generally just use the systems provided
by their employers. The majority don't have sys admin style access to
the systems, so installing and building gcc 7
is not an option.

Hope this helps.

>
> Damian
>

[Tim Prince]

The bootstrap update (including download) with --enable-languages='c c++
fortran' took nearly 2 hours on the 8 year old 4-core CPU. I'm looking
to see whether today's update can survive make -k check-fortran (and
check-c). If so, I'll post on gcc testresults with "wsl" appended to
the target title.

By the way, clf is no longer showing up in my Win10 installation. One
more reason to restrict Win10 to my oldest box.

[tim prince]

Somehow, clf fell into the "ignored threads" on my Win10.
More to the point, I just discovered 'sudo apt-get install dist-upgrade'
which looks like an important FAQ for wsl.

--
Tim Prince

[JB]

On 2016-12-29, Tim Prince <tpr...@computer.org> wrote:
> I didn't need disable-bootstrap; it seems better to go through bootstrap
> to be more sure of things.

Yes, it's better, provided you have the patience.

> The requirement for --disable-multilib is associated with the
> non-support of 32-bit mode in WSL. Also, the scheme for libraries seems
> to be somewhat like standard linux, with /lib64 and the like, rather
> than following older Ubuntu practice.

That's what the default GCC autotools setup uses. Ubuntu (and Debian,
from which the scheme was copied) use a patched configury for their
own builds.

The Debian/Ubuntu scheme is actually newer than the /lib64 scheme and
has some benefits, but the old lib64 scheme is already more or less a
de-facto standard, so...

> Will supporting gfortran on WSL become a priority to the extent that the
> testsuite may be useful?

Depends on somebody taking an interest in it and stepping up to the
plate. There's no high priest giving instructions what should be
prioritized and what not.

> Does this mean gfortran 6.3 will be the last version to be supported
> directly on Windows?

AFAIK there are no plans to drop mingw and cygwin support.


--
JB

[tim prince]

On 12/31/2016 4:37 PM, Tim Prince wrote:

Last night's trunk build was able to complete gfortran testsuite (but
not gcc) so I posted it (search for WSL on gcc testresults). I will
post gcc-6 results for C and C++ as well as gfortran, if those complete.

--
Tim Prince