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_AUTOMAK
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
I sent David a patch to test - will wait to commit to trunk until I hear from
him, then will CMR.
On May 23, 2012, at 3:23 PM, Jeff Squyres 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 th
It shouldn't be before AM_INIT_AUTOMAKE, that's just busted and needs to
be fixed in hwloc...
Brian
On 5/23/12 3:23 PM, "Jeff Squyres" 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
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!
>
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 s
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
mean
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,
Thanks!
On Wed, May 23, 2012 at 4:38 PM, Ralph Castain wrote:
> It did, however, serve one purpose - it made me look closer at the
> Java-related configury and find an error (we were -always- building Java
> bindings).
>
> I added the flag Josh mentioned, so --disable-java will turn off *all*
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
It did, however, serve one purpose - it made me look closer at the Java-related
configury and find an error (we were -always- building Java bindings).
I added the flag Josh mentioned, so --disable-java will turn off *all*
Java-related code.
Thanks Josh
On May 23, 2012, at 2:31 PM, Josh Hursey
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 t
To follow up on this thread for the list. I can no longer reproduce
this configure error. It existed, really it did... :/
After a maintenance cycle on the machine and updating to the current
trunk all was fine. The configure logic in the trunk did the right
thing. When it did not find a java compi
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
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
===
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=./o
No, we just need to get the built files completely removed from the repo. I've
been working on it.
On May 23, 2012, at 12:10 PM, Rolf vandeVaart wrote:
> After doing a fresh checkout of the trunk, and then running autogen, I see
> this:
>
> M opal/mca/event/libevent2019/libevent/Makefil
After doing a fresh checkout of the trunk, and then running autogen, I see this:
M opal/mca/event/libevent2019/libevent/Makefile.in
M opal/mca/event/libevent2019/libevent/depcomp
M opal/mca/event/libevent2019/libevent/include/Makefile.in
M opal/mca/event/libevent2019/libeve
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
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"
FCFL
Thanks. I figured it was just overlooked since most systems have a
java compiler installed in normal locations these days.
-- Josh
On Wed, May 23, 2012 at 8:56 AM, Ralph Castain wrote:
> I'll fix that - yes, you should be able to build if no Java compiler is found.
>
>
> On May 23, 2012, at 6:51
I'll fix that - yes, you should be able to build if no Java compiler is found.
On May 23, 2012, at 6:51 AM, Josh Hursey wrote:
> Is there a way to build Open MPI without a Java compiler?
>
> Meaning, I have no Java compiler on a particular machine, and
> '--disable-mpi-java' disables only the J
Is there a way to build Open MPI without a Java compiler?
Meaning, I have no Java compiler on a particular machine, and
'--disable-mpi-java' disables only the Java bindings and not the Java
compiler check. If the Java compiler check fails to find a compiler
then configure currently fails.
-- Josh
23 matches
Mail list logo
