[mvapich-discuss] Trouble building MVAPICH2-1.5 shared libraries with Pathscale compiler

[Adam T. Moody]

Hi Pavan,
Sounds good.  In my patch, I just copied the existing pattern in the 
config file and applied it to cover the PathScale case.

Looking at the diff on the link you sent, it looks like FC_SHL is set by 
testing various options, but it's not clear to me that F90_SHL is set in 
a similar way.  In fact, it still looks like there is a case statement 
based on the compiler vendor (gnu vs absoft vs intel vs pgi).  So long 
as some mechanism lets PathScale builds work, I'm happy.
-Adam

Pavan Balaji wrote:

>Adam,
>
>It's probably not a good idea to check specifically for the pathscale 
>compiler. Instead, doing a feature test on the compiler on what it 
>accepts and what it doesn't might be better.
>
>We had encountered this bug recently, and it was fixed in r6604 in 
>MPICH2: https://*trac.mcs.anl.gov/projects/mpich2/changeset/6604
>
>This patch should directly apply for MVAPICH2 as well.
>
>  -- Pavan
>
>On 07/22/2010 07:21 PM, Adam T. Moody wrote:
>  
>
>>Hello MVAPICH team,
>>I've attached a patch to get MVAPICH2-1.5 to build shared libraries 
>>using the Pathscale 3.2.99 compiler.  I patched 'configure', so you'll 
>>probably have to port this to 'configure.in' or something else.  Also, 
>>I'd recommend changing the configure warning for an "unknown" F90 shared 
>>library compile command to a fatal error for users who want to build 
>>shared libraries.  I haven't tested a run, but at least the MPI builds, 
>>and I can apparently link to the resulting shared library via a simple 
>>MPI F90 program.  Here is the background:
>>
>>I'm trying to get a build of MVAPICH2-1.5 with shared libraries using 
>>the Pathscale 3.2.99 compiler, but I get the following error during the 
>>build.
>>
>>make[5]: Entering directory 
>>`/tmp/dpkg-mkdeb.QmhTI32413/src/build-mvapich-long-path-hack-enabled-ofa-pathscale-debug/src/binding/f90'
>>  CC              create_f90_int.c
>>  CC              create_f90_real.c
>>  CC              create_f90_complex.c
>>  CC              typef90cmplxf.c
>>  CC              typef90realf.c
>>  CC              typef90intf.c
>>  CC              create_f90_util.c
>>  AR cr ../../../lib/libmpich.la create_f90_int.lo create_f90_real.lo 
>>create_f90_complex.lo typef90cmplxf.lo typef90realf.lo typef90intf.lo 
>>create_f90_util.lo
>>date > .libstamp1
>>make[5]: Leaving directory 
>>`/tmp/dpkg-mkdeb.QmhTI32413/src/build-mvapich-long-path-hack-enabled-ofa-pathscale-debug/src/binding/f90'
>>make[5]: Entering directory 
>>`/tmp/dpkg-mkdeb.QmhTI32413/src/build-mvapich-long-path-hack-enabled-ofa-pathscale-debug/src/binding/f90'
>>  F90             mpi.f90
>>make[5]: *** [mpi.lo] Error 1
>>
>>When I cd into the build directory and run "make VERBOSE=1", I see the 
>>following:
>>
>>zeus286<73>: make VERBOSE=1
>>make[1]: Entering directory 
>>`/tmp/dpkg-mkdeb.QmhTI32413/src/build-mvapich-long-path-hack-enabled-ofa-pathscale-debug/src/binding/f90'
>>make[1]: `.libstamp1' is up to date.
>>make[1]: Leaving directory 
>>`/tmp/dpkg-mkdeb.QmhTI32413/src/build-mvapich-long-path-hack-enabled-ofa-pathscale-debug/src/binding/f90'
>>make[1]: Entering directory 
>>`/tmp/dpkg-mkdeb.QmhTI32413/src/build-mvapich-long-path-hack-enabled-ofa-pathscale-debug/src/binding/f90'
>>false -g -O0 -fno-second-underscore -g -O0 -I. -c mpi.f90 -o _smpi.o
>>mv -f _smpi.o mpi.lo
>>make[1]: *** [mpi.lo] Error 1
>>make[1]: Leaving directory 
>>`/tmp/dpkg-mkdeb.QmhTI32413/src/build-mvapich-long-path-hack-enabled-ofa-pathscale-debug/src/binding/f90'
>>make: *** [all-redirect] Error 1
>>
>>Apparently, it's trying to use "false" as the name of the Fortran 
>>compiler.  Looking at the Makefile in this directory, I see the F90_SHL 
>>macro is set to "false" instead of something like "pathf90 -shared 
>>-fpic", which is what I suspect it should be.  (In fact, if I hard code 
>>this in, then the make works.)
>>
>>CC              = pathcc
>>CFLAGS          =  -g -O0 -g -O0 $(MPICH2_MAKE_CFLAGS)
>>C_COMPILE       = $(CC) $(DEFS) $(INCLUDES) $(CFLAGS) $(CPPFLAGS)
>>LIBTOOL         =
>>CC_SHL          = ${CC} -fpic
>>C_COMPILE_SHL   = $(CC_SHL) $(DEFS) $(INCLUDES) $(CFLAGS) $(CPPFLAGS)
>>F90              = pathf90
>>F90FLAGS        =  -g -O0 -fno-second-underscore -g -O0
>>F90_COMPILE     = $(F90) $(F90FLAGS) $(F90INCLUDES)
>>F90_SHL          = false
>>F90_COMPILE_SHL = $(F90_SHL) $(F90FLAGS) $(F90INCLUDES)
>>
>>Looking at the main configure file around line 13287, I see tests for 
>>various compilers, but none specifically for Pathscale.  These tests 
>>apparently look for strings in the verion output of the F90 compiler.  
>>For reference, here is what I get with "pathf90 --version":
>>
>>zeus286<94>: pathf90 --version
>>PathScale(TM) Compiler Suite: Version 3.2.99
>>Built on: 2009-08-21 13:23:57 -0500
>>Thread model: posix
>>GNU gcc version 4.2.0 (PathScale 3.2.99 driver)
>>
>>Copyright 2000, 2001 Silicon Graphics, Inc.  All Rights Reserved.
>>Copyright 2002, 2003, 2004, 2005, 2006 PathScale, Inc.  All Rights Reserved.
>>Copyright 2006, 2007 QLogic Corporation.  All Rights Reserved.
>>Copyright 2007, 2008 PathScale LLC.  All Rights Reserved.
>>See complete copyright, patent and legal notices in the
>>/usr/local/tools/pathscale-3.2.99/share/doc/pathscale-compilers-3.2.99/LEGAL.pdf 
>>file.
>>
>>In order to support the Pathscale compiler for shared libraries, I 
>>suppose a test should be added to look for "PathScale" and then set 
>>"F90_SHL = $(F90) -fpic".  This is what the included patch does.  In 
>>addition, it may be good to assume "F90_SHL = $(F90) -fpic" if the 
>>compiler is unknown or otherwise throw a fatal error during the 
>>configure.  I'd be happy to help test out a fix.
>>Thanks,
>>-Adam
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>mvapich-discuss mailing list
>>mvapich-discuss at cse.ohio-state.edu
>>http://*mail.cse.ohio-state.edu/mailman/listinfo/mvapich-discuss
>>    
>>
>
>  
>