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/
