Yup, it sucks. But that's not supported functionality. Someone could possibly desire to support it, but I could never get behavior I was comfortable with, so I'm not making promises that should work. The platform thing is a real hack to begin with in terms of what it does to autoconf...
Brian On 5/23/12 2:37 PM, "Gunter, David O" <d...@lanl.gov> wrote: >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 > > >_______________________________________________ >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
