Here's the patch I provided - seems to work just fine. Just waiting for David's confirmation on his system.
config.diff
Description: Binary data
On May 23, 2012, at 7:50 PM, Jeff Squyres wrote: > On May 23, 2012, at 5:25 PM, Barrett, Brian W wrote: > >> It shouldn't be before AM_INIT_AUTOMAKE, that's just busted and needs to >> be fixed in hwloc... > > I don't think that's right. It's an AC macro, not an AM macro, so it can > come before AM_INIT_AUTOMAKE. > > Here's what happens if you put it before AM_INIT_AUTOMAKE: > > ---- > [21:49] jsquyres-mac:~/tmp/foo % cat configure.ac > AC_INIT([bogus], [1.0], [http://example.com], [bogus]) > AC_CONFIG_AUX_DIR(./config) > AC_CONFIG_MACRO_DIR(./config) > > AC_CANONICAL_TARGET > AM_INIT_AUTOMAKE([1.10 foreign -Wall -Werror]) > > AC_CONFIG_FILES([Makefile]) > AC_OUTPUT > [21:49] jsquyres-mac:~/tmp/foo % autoreconf -ivf && ./configure > autoreconf: Entering directory `.' > ....it works fine > ----- > > But if you flip CANONICAL_TARGET / INIT_AUTOMAKE: > > ----- > [21:50] jsquyres-mac:~/tmp/foo % autoreconf -ivf && ./configure > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal --force > configure.ac:6: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET > ../../lib/autoconf/general.m4:1834: AC_CANONICAL_TARGET is expanded from... > configure.ac:6: the top level > autoreconf: configure.ac: tracing > configure.ac:6: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET > ../../lib/autoconf/general.m4:1834: AC_CANONICAL_TARGET is expanded from... > configure.ac:6: the top level > autoreconf: configure.ac: not using Libtool > autoreconf: running: /opt/local/bin/autoconf --force > configure.ac:6: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET > ../../lib/autoconf/general.m4:1834: AC_CANONICAL_TARGET is expanded from... > configure.ac:6: the top level > autoreconf: configure.ac: not using Autoheader > autoreconf: running: automake --add-missing --copy --force-missing > configure.ac:6: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET > ../../lib/autoconf/general.m4:1834: AC_CANONICAL_TARGET is expanded from... > configure.ac:6: the top level > autoreconf: Leaving directory `.' > .........etc. > ----- > > configure does seem to run ok, but I didn't include any other tests (like > AC_PROG_CC), etc. I have a dim recollection that other things would break, > but am too tired to test that right now. > > >> Brian >> >> On 5/23/12 3:23 PM, "Jeff Squyres" <jsquy...@cisco.com> wrote: >> >>> Yea, the CANONICAL_HOST thing is because of hwloc; sorry... It needs to >>> be very, very early in configure.ac. So getting the ordering wrong there >>> was probably my fault; sorry. >>> >>> On May 23, 2012, at 4:53 PM, Ralph Castain wrote: >>> >>>> Ah, okay - didn't realize that ordering. I'll fix it - thanks! >>>> >>>> On May 23, 2012, at 2:49 PM, Barrett, Brian W wrote: >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> -- >>> Jeff Squyres >>> jsquy...@cisco.com >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> 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 > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
