Modify GCC build system to build MPICH

[rouson]

Request for Enhancement (RFE)

As a first step to integrating the building of OpenCoarrays into the GCC build system, let's patch the GCC build system to build the OpenCoarrays prerequisite MPICH 3.2.1.

[rouson]

@dcelisgarza has created and pushed a build-mpich branch for this work.

[rouson]

@dcelisgarza

FWIW, it occurs to me that MPICH and OpenCoarrays occupy bit of an unusual position in which it might make the sense to thing of them as "co-requisites" instead of prerequisites. This matters wherever the build system honors build order: gcc and gfortran are prerequisites for building OpenCoarrays; whereas OpenCoarrays is a prerequisite for using gfortran (at least if the use involves parallel features of Fortran). You'll want to make sure the build system does the following in order:

1. Build gcc and g++
2. Build gfortran
3. Set the LD_LIBRARY_PATH environment variable to contain the just-built lib64 directory.
4. Us the just-built gcc to build an MPI implementation.
5. Use the just-built mpicc and mpifort to build

• The caf_mpi libraries (including .a, .la, and .so, assuming each is appropriate)
• The caf and cafrun bash scripts
• The lib/opencoarrays.a library and include/opencoarrays.mod mod files (and .so and .la if appropriate)

I have quite often forgotten step 3 and found it to be catastrophic when all tests fail because of linking to the wrong library.

[jerryd]

Yes, this sequence seems right. You may notice that libgfortran gets built after the gfortran frontend because some of the libgfortran and some instrinsic modules are written in Fortran. Also note that the gcc build has three phases when being bootstrapped, no need to build gfortran or anything else until the final stage. The earlier stages are to make sure the C and C++ compilers are correct before moving on, as you have in Step 1.

Step 3 is actually defined by the --prefix given to ./configure and no need to set LD_LIBRARY_PATH until after all is done and you want to actually use the compiler. The gnu build system will let you access that prefix value during make processes.

I am setting up a new laptop here. I noticed that my configure fails because on this multilib system, the mpich library installed from the Fedora distrubution plaes libmpi.* in /usr/lib64/mpich/lib. This is non standard and my research on this indicates that when using the gnu build system, the user is responsible to specify the path in the configure invocation line. In configure.ac you see I used pkg-config to assist in this case. Well I dont have that set up on this laptop yet and so it fails to find libmpi.

Other systems, like Ubuntu, place libmpi in /usr/lib on 64 bit systems. This does conform to the standard.

My point in all this is that gcc build machinery is doing some "magic" to handle the multilib world you find in systems like Fedora that can have dual libraries, 32 and 64 bit, at the same time. We only need 64 bit for Opencoarrays.