Problems building mpich

General

1. Q: When running make on mpich, I get this error:


ar: write error: No such file or directory 
*** Error code 1 

I've looked, and all the files are accessible and have the proper permissions.


A: Check the amount of space in /tmp. This error is sometimes generated when there is insufficient space in /tmp to copy the archive (this is a step that ar takes when updating a library). The command df /tmp will show you how much space is available. Try to insure that at least twice the size of the library is available.


2. Q: When running make on mpich, I get errors when executing ranlib.


A: Many systems implement ranlib with the ar command, and they use the /tmp directory by default because it ``seems'' obvious that using /tmp would be faster (/tmp is often a local disk). Unfortunately, some systems have ridiculously small /tmp partitions, making any use of /tmp very risky. In some cases, the ar commands used by mpich will succeed because they use the l option---this forces ar to use the local directory instead of /tmp. The ranlib command, on the other hand, may use /tmp and cannot be fixed.

In some cases, you will find that the ranlib command is unnecessary. In these cases, you can reconfigure with -noranlib. If you must use ranlib, either reduce the space used in /tmp or increase the size of the /tmp partition (your system administrator will need to do this). There should be at least 20--30 MBytes free in /tmp.


3. Q: When doing the link test, the link fails and does not seem to find any of the MPI routines:




  /homes/me/mpich/IRIX32/ch_p4/bin/mpicc -o overtake overtake.o test.o  
ld: WARNING 126: The archive /homes/me/mpich/IRIX32/ch_p4/lib/libmpi.a  
  defines no global symbols. Ignoring. 
ld: WARNING 84: /usr/lib/libsun.a is not used for resolving any symbol. 
ld: ERROR 33: Unresolved data symbol "MPI_COMM_WORLD" -- 1st referenced  
  by overtake.o. 
ld: ERROR 33: Unresolved text symbol "MPI_Send" -- 1st referenced by  
  overtake.o. 
... 


A: Check that the ar and ranlib programs are compatible. One site installed the Gnu ranlib in such a way that it would be used with the vendors ar program, with which it was incompatible. Use the -noranlib option to configure if this is the case.

Workstation Networks

1. Q: When building mpich, the make fails with errors like this:


making p4 in directory lib 
        make  libp4.a 
        cc -Aa -g -I../include -I../../../../include   -c p4_globals.c  
cc: "/usr/include/netinet/in.h", line 69: error 1000: Unexpected symbol: "u_long". 
cc: "/usr/include/netinet/in.h", line 127: error 1000: Unexpected symbol: "u_short". 

etc.


A: The problem here is that the system (not mpich) include files are incompatible with your choice of compiler. Check to see if cc is aliased (in C shell, do alias cc). If it is, either unalias it or set the environment variable CC to the full path for the compiler. To get the full path, do


unalias cc 
setenv CC `which cc` 

and then reconfigure.

Cray T3D

1. Q: When linking I get


 mppldr-133 cf77: CAUTION 
     Unsatisfied external references have been encountered. 
 
 Unsatisfied external references 
 Entry name      Modules referencing entry 
 
 GETARG (equivalenced to $USX1) 
                 MPIR_GETARG 


A: You may have specified the Fortran compiler with the F77 environment variable or the -fc argument to configure. The mpich Fortran implemenation of MPI uses a common Fortran extension, GETARG, to get the command line arguments. Most Fortran runtime systems support this, but Cray uses call pxfgetarg(i,s,len(s),ierr) instead. You can change the file src/env/farg.f manually to call the correct routine (but note that configure builds a new farg.f from farg.f.in each time that it is run).

Mpich now attempts to determine the correct names of the routines to access the command line. If you find that mpich fails to determine the names correctly, please send a bug report to [email protected].

SGI

1. Q: The build on an SGI Power Challenge fails with


Signal: SIGSEGV in Back End Driver phase. 
> ### Error: 
> ### Signal SIGSEGV in phase Back End Driver -- processing aborted 
> f77 ERROR:  /usr/lib64/cmplrs/be died due to signal 4 
> f77 ERROR:  core dumped 
> *** Error code 2 (bu21) 
> *** Error code 1 (bu21) 
> *** Error code 1 (bu21) 


A: Our information is that setting the environment variable SGI_CC to -ansi will fix this problem.


2. Q: The build on an SGI with architecture IRIXN32 fails with




cc: Warning: -c should not be used with ucode -O3 -o32  
             on a single file; use -j instead to get inter-module  
             optimization. 


A: Amazingly, the standard -c option is not valid for the SGI compilers when both -O3 and -n32 are specified. This is a ``feature'' of the SGI compiler, and there is no way to work around this for mpich (other than a massive and non-portable rewrite of all the Makefiles). Your only option is to not use the -O3 option.

Linux

1. Q: The link test failed on Linux with


... 
cc  -o overtake overtake.o test.o -L/usr/local/mpich/LINUX/ch_p4/lib 
-lmpi  
overtake.o(.text+0x71): undefined reference to `MPI_COMM_WORLD' 
overtake.o(.text+0x82): undefined reference to `MPIR_I_DOUBLE' 
overtake.o(.text+0xe1): undefined reference to `MPI_COMM_WORLD' 
... 


A: We have been informed that there is a error in the f77 script in some versions of Linux which causes this problem. Try either getting a patch for the f77 script or reconfiguring with -nof77.


2. Q: The build fails for the ch_p4 device when using the Compaq C compiler.


A: There is an incompatibility with the system include files (not the mpich include files). If you can modify /usr/include/rpc/xdr.h, add the following near the top of that file:


    #if defined(__DECC) || defined(__DECCXX) 
    typedef long int int64_t; 
    #endif 

Compaq ULTRIX and Tru64

1. Q: When trying to build, the make aborts early during the cleaning phase:


amon:MPICH/mpich>make clean 
        /bin/rm -f *.o *  nupshot 
*** Error code 1 


A: This is a bug in the shell support on some Compaq ULTRIX systems. You may be able to work around this with




setenv PROG_ENV SYSTEM_FIVE 

Configuring with -make=s5make may also work.