Not sure what you mean; the file's loaded in OMPI_LOAD_PLATFORM, at which point all the contents of the file are evaluated as environment variables. The real problem is that someone really screwed up configure somewhere along the way and called AC_CONONICAL_HOST before AM_INIT_AUTOMAKE, which means AC_PROG_GCC got evaluated really early, before OMPI_LOAD_PLATFORM is evaluated. It really needs to be evaluated before any non-init macros.
Brian On 5/23/12 2:44 PM, "Ralph Castain" <r...@open-mpi.org> wrote: >I'm looking at it... > >We pickup the file at the right place, but we don't pull any of the flags >out of it until later. I'm trying to see if I can adjust it. > >BTW: none of this changed from the 1.5 series, so this has been the >situation for a very long time. > > >On May 23, 2012, at 2:41 PM, Barrett, Brian W wrote: > >> 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 >> >> >> >> >> >> >> _______________________________________________ >> 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
