So perhaps I should stop calling them environment variables. Since one can always do something like
$ ./configure CFLAGS="-I/usr/include/specialK" ... a line such as CFLAGS="-I/usr/include/specialK" should be supported by the platform file reader. No two systems are alike here and we need these platform files to manage the dozens of different OMPI builds. We have different paths for the IB libs, Panasas file system libs and includes, etc. Essentially, we're not going to 1.6 at the moment. -david -- David Gunter HPC-3: Infrastructure Team Los Alamos National Laboratory On May 23, 2012, at 2:23 PM, Barrett, Brian W wrote: > David - > > Where exactly the platform file gets evaluated depends on a number of > things that the OMPI developers don't have a lot of control over. It was > never meant to be used to set environment variables, only command line > arguments. It looks like something bad has happened with ordering; I'm > not sure when I'll be able to take a look, but we should be able to make > it evaluate sooner... > > Brian > > On 5/23/12 2:16 PM, "Gunter, David O" <d...@lanl.gov> wrote: > >> I think I have some understanding of what is happening. In version 1.6, >> the check for the platform file occurs after some basic compiler testing >> has already occured: >> >> (dog@tu-fe1 61%) ./configure --with-platform=non-existant >> >> ========================================================================== >> == >> == Configuring Open MPI >> ========================================================================== >> == >> >> *** Startup tests >> checking build system type... x86_64-unknown-linux-gnu >> checking host system type... x86_64-unknown-linux-gnu >> checking target system type... x86_64-unknown-linux-gnu >> checking for gcc... gcc >> checking whether the C compiler works... yes >> checking for C compiler default output file name... a.out >> checking for suffix of executables... >> checking whether we are cross compiling... no >> checking for suffix of object files... o >> checking whether we are using the GNU C compiler... yes >> checking whether gcc accepts -g... yes >> checking for gcc option to accept ISO C89... none needed >> checking how to run the C preprocessor... gcc -E >> checking for grep that handles long lines and -e... /bin/grep >> checking for egrep... /bin/grep -E >> checking for ANSI C header files... yes >> checking for sys/types.h... yes >> checking for sys/stat.h... yes >> checking for stdlib.h... yes >> checking for string.h... yes >> checking for memory.h... yes >> checking for strings.h... yes >> checking for inttypes.h... yes >> checking for stdint.h... yes >> checking for unistd.h... yes >> checking minix/config.h usability... no >> checking minix/config.h presence... no >> checking for minix/config.h... no >> checking whether it is safe to define __EXTENSIONS__... yes >> configure: error: platform file non-existant not found >> (dog@tu-fe1 62%) >> >> For OMPI 1.4.5, the platform file check occurs right off: >> >> (dog@tu-fe1 13%) ./configure --with-platform=non-existant >> configure: error: platform file non-existant not found >> >> >> As it is in the newer release, it will fail to work for the PGI compilers >> then. >> >> -david >> >> -- >> David Gunter >> HPC-3: Infrastructure Team >> Los Alamos National Laboratory >> >> >> >> >> On May 23, 2012, at 12:21 PM, Gunter, David O wrote: >> >>> I thought the purpose of the platform file was to be equivalent to >>> setting things on the command-line to configure. Still, it has always >>> worked that way for us. >>> >>> Here's what I'm seeing: >>> >>> (dog@lo1-fe 297%) ./configure >>> --prefix=/usr/projects/hpcsoft/lobo/openmpi/1.6.0-pgi-12.4 >>> --with-platform=./optimized-panasas-pgi >>> >>> >>> ========================================================================= >>> === >>> == Configuring Open MPI >>> >>> ========================================================================= >>> === >>> >>> *** Startup tests >>> checking build system type... x86_64-unknown-linux-gnu >>> checking host system type... x86_64-unknown-linux-gnu >>> checking target system type... x86_64-unknown-linux-gnu >>> checking for gcc... >>> /usr/projects/hpcsoft/lobo/pgi/linux86-64/12.4/bin/pgcc >>> checking whether the C compiler works... no >>> configure: error: in `/usr/projects/hpctools/dog/openmpi/openmpi-1.6': >>> configure: error: C compiler cannot create executables >>> See `config.log' for more details >>> >>> >>> The error happens because this particular compiler, pgi-12.4, needs two >>> flags: -lnomp and -lnuma. Thus the reason for the LDFLAGS line in the >>> platform file. >>> >>> If I compile like this: >>> >>> (dog@lo1-fe 297%) ./configure >>> --prefix=/usr/projects/hpcsoft/lobo/openmpi/1.6.0-pgi-12.4 >>> --with-platform=./optimized-panasas-pgi LDFLAGS="-nomp -lnuma" >>> >>> Then the configure proceeds normally. >>> >>> -david >>> -- >>> David Gunter >>> HPC-3: Infrastructure Team >>> Los Alamos National Laboratory >>> >>> >>> >>> >>> On May 23, 2012, at 12:03 PM, Jeff Squyres (jsquyres) wrote: >>> >>>> Can you send some output showing that those flags aren't passed >>>> through, like some output from "make V=1" and or from config.log? >>>> >>>> Offhand, I don't know if we ever formally supported setting env >>>> variables other than enable and with flag variables in the platform >>>> files...? >>>> >>>> Sent from my phone. No type good. >>>> >>>> On May 23, 2012, at 12:49 PM, "Gunter, David O" <d...@lanl.gov> wrote: >>>> >>>>> I am trying to set LDFLAGS, CFLAGS, etc, in a platform file but the >>>>> 1.6 release does not seem to pick these up. >>>>> >>>>> Here's the tail end of one of our platform files, for building with >>>>> the latest PGI compilers: >>>>> >>>>> LDFLAGS="-nomp -lnuma" >>>>> CFLAGS="-I/opt/panfs/include" >>>>> CXXFLAGS="-I/opt/panfs/include" >>>>> FCFLAGS="-I/opt/panfs/include" >>>>> FFLAGS="-I/opt/panfs/include" >>>>> CCASFLAGS="-I/opt/panfs/include" >>>>> >>>>> The same platform file will configure the 1.4.5 release just fine but >>>>> does not work with 1.6. If I set these variables in my environment and >>>>> then run configure, it works just fine - as expected. >>>>> >>>>> Has anyone else noticed this behavior? >>>>> >>>>> -david >>>>> -- >>>>> David Gunter >>>>> HPC-3: Infrastructure Team >>>>> Los Alamos National Laboratory >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> devel mailing list >>>>> de...@open-mpi.org >>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> de...@open-mpi.org >>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> > > > -- > Brian W. Barrett > Dept. 1423: Scalable System Software > Sandia National Laboratories > > > > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
