autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Autoconf MPI macros


From: Christian Rössel
Subject: Re: Autoconf MPI macros
Date: Wed, 8 Jun 2011 11:16:45 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10

On 05/24/2011 06:16 PM, Daily, Jeff A wrote:
>> -----Original Message-----
>
>> From: address@hidden [mailto:autoconf-
>
>> address@hidden On Behalf Of Olaf Lenz
>
>> Sent: Tuesday, May 24, 2011 2:02 AM
>
>> To: address@hidden; address@hidden; Steven G.
>
>> Johnson; Julian C. Cummings
>
>> Subject: Autoconf MPI macros
>
>>
>
>> Hi all!
>
>>
>
>> We are using the GNU autotools and MPI in a number of our projects, and
>
>> we found that the AX_MPI macro from the autoconf macro archive has a few
>
>> shortcomings.
>
>>
>
>> The problem is that AX_MPI starts to do anything only after the standard C
>
>> compiler has been found via AC_PROG_CC. If you want to compile the whole
>
>> package using MPI and simply replace CC with the MPI compiler, this can lead
>
>> to serious trouble. Assume the following case (seen on an IBM AIX machine):
>
>> * gcc is installed
>
>> * the MPI compiler is xlc (the IBM compiler)
>
>>
>
>> If I use AX_MPI in configure.ac, the following will happen in configure:
>
>> * AC_PROG_CC will recognize "gcc" as standard C compiler
>
>> * it will furthermore determine the options that gcc uses to generate
>
>> dependencies
>
>> * then, AX_MPI will recognize the MPI compiler "xlc"
>
>> * CC will be set to "xlc"
>
>>
>
>> When I compile, this means that the compiler tries to generate
>
>> dependencies using the compiler xlc with the options of gcc. In this 
>> particular
>
>> case, the option (-MD if I'm not mistaken) caused xlc to output profiling
>
>> information into the .c-file and thus effectively destroyed the C-code.
>
>>
>
>> I believe that the correct way to avoid this problem is a set of new macros
>
>> AX_PROG_{FC,CCCXX}_MPI that are used in configure.ac instead of
>
>> AC_PROG_{CC,FC,CXX}. I have attached the macro AX_PROG_CC_MPI, and a
>
>> git clone of the autoconf macro archive containing the macro can be found at
>
>>
>
>>   https://github.com/olenz/autoconf-archive
>
>>
>
>> Internally, the MPI macro uses the standard macro AC_PROG_CC to find the
>
>> compiler, and directly sets CC to a working MPI version.
>
>>
>
>> I propose to include these macros into the autoconf macro archive, and to
>
>> extend the docs of AX_MPI to point to these macros.
>
>>
>
>> Greetings
>
>>   Olaf
>
>>
>
>> --
>
>> Dr. rer. nat. Olaf Lenz
>
>> Institut für Computerphysik, Pfaffenwaldring 27, D-70569 Stuttgart
>
>> Phone: +49-711-685-63607
>
>
>
> There are additional shortcomings that we noticed while trying to use MPI 
> compilers with autotools.  Specifically to autoconf, on some systems the MPI 
> compilers produce incorrect results for the AC_F77_LIBRARY_LDFLAGS test.  We 
> use AC_PROG_CC, AC_PROG_F77, and AC_PROG_CXX and pass in a well-known list of 
> possible MPI compilers to search for so that CC, F77, and CXX are set and 
> used throughout the configure script.  However, we then immediately "unwrap" 
> the MPI compilers to determine the standard compilers.  We pass the unwrapped 
> compilers to AC_F77_LIBRARY_LDFLAGS.

I encountered AC_F77_LIBRARY_LDFLAGS shortcomings only with Oracle/Sun
studio compiler and MPI wrappers based on this compiler. But with your
additions to _AC_FC_LIBRARY_LDFLAGS, namely _GA_FC_LIBRARY_LDFLAGS, this
macro gets you the desired result.

I'm not sure if I fully understand what you are doing in
GA_F77_LIBRARY_LDFLAGS but I think that your changes to
_AC_FC_LIBRARY_LDFLAGS should be included in the next autoconf release
as they fix the problem with the studio compiler.

I attached a patch with your changes against git head. If this is going
to be pushed, please don't credit me but Jeff for this contribution.


>
>
> Further, if you're using libtool, you must pass the unwrapped compilers to 
> libtool because libtool unfortunately compares against compiler names.  Worse 
> yet, after libtool is finished with its tests, we have to substitute back in 
> the MPI compilers which is a hack, at best.

I ran into trouble using libtool with PGI and Intel based Fortran MPI
compiler wrappers too. But with recent patches [1] [2] I have no
problems using the compiler wrappers (gcc, Intel, IBM, PGI, Cray)
directly with libtool, except for the Oracle/Sun studio compiler in
shared library mode.

Christian

[1]
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=92eb89aace9fd41e43eee33f5c392adf1bcf8963
[2]
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=39ba8c55de025805c69d46e76f1a352658e01382

>
> Of course, if the user passes the MPI include paths, library paths, and MPI 
> libraries manually then there is no issue since a standard compiler is then 
> used throughout.  We only have issues trying to use the MPI compilers.  Our 
> default is to use the compiler wrappers, but we allow the user to pass 
> arguments to our --with-mpi option which then disables the use of the MPI 
> compilers.
>
>
>
> I've attached hopefully all relevant m4 files we use in our project, Global 
> Arrays.
>
> Website: http://www.emsl.pnl.gov/docs/global/
>
> SVN: https://svn.pnl.gov/hpctools
> _________________________________________________
> Jeff Daily
> Scientist
> DATA INTENSIVE SCIENTIFIC COMPUTING
> Pacific Northwest National Laboratory
> 902 Battelle Boulevard
> P.O. Box 999, MSIN K7-90
> Richland, WA  99352 USA
> Tel:  509-372-6548
> Fax: 509-372-4720
> address@hidden
> www.pnnl.gov
>
>
>


--
Christian Rössel
Jülich Supercomputing Centre
Telefon +49 2461 61-1773

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de

Attachment: _AC_FC_LIBRARY_LDFLAGS.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]