Ralph and Nathan,
As I said, the results I see fail to match the actual ALPS header locations
on both CLE4 and CLE5 systems at NERSC.
However, the CLE4 system "just works" because the actual location
(/usr/include) gets searched no matter what value configure picks for
$orte_check_alps_dir. I suspect that this is why you didn't see any errors
on LANL's system.
Regardless of the defaults, there is still an additional issue with
orte_check_alps.m4 that occurs when I give an explicit
with-alps=/opt/cray/alps/default in the platform file, which the following
bit of config.log confirms:
> configure:99227: checking --with-alps value
> configure:99247: result: sanity check ok (/opt/cray/alps/default)
> configure:99329: checking for alps libraries in
> "/opt/cray/alps/default/lib64"
> configure:99334: result: found
However, when trying to configure the ras:alps component, the value of
ras_alps_CPPFLAGS does not contain "-I/opt/cray/alps/default/include" as I
would have expected from reading the relevant .m4 files and the generated
configure script:
> configure:113697: checking for MCA component ras:alps compile mode
> configure:113703: result: static
> configure:113871: checking alps/apInfo.h usability
> configure:113871: gcc -std=gnu99 -c -O3 -DNDEBUG -march=amdfam10
> -finline-functions -fno-strict-aliasing -fexceptions -pthread
> -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/opal/mca/hwloc/hwloc151/hwloc/include
> -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/BUILD-edison-gcc/opal/mca/hwloc/hwloc151/hwloc/include
> -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/opal/mca/event/libevent2019/libevent
> -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/opal/mca/event/libevent2019/libevent/include
> -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/BUILD-edison-gcc/opal/mca/event/libevent2019/libevent/include
> -I/opt/cray/pmi/default/include -I/opt/cray/pmi/default/include
> -I/opt/cray/pmi/default/include -I/opt/cray/pmi/default/include conftest.c
> >&5
> conftest.c:640:25: fatal error: alps/apInfo.h: No such file or directory
> compilation terminated.
> configure:113871: $? = 1
While only 95% certain, I think that this logic
in config/orte_check_alps.m4 is to blame:
> if test "$with_alps" = "no" -o -z "$with_alps" ; then
> orte_check_alps_happy="no"
> else
> # Only need to do these tests once (this macro is invoked
> # from multiple different components' configure.m4 scripts
Specifically, the setting of "$1_CPPFLAGS" appears to be ERRONEOUSLY placed
within the else-clause of the logic above. So, when
orte/mca/ess/alps/configure.m4 is run BEFORE
orte/mca/ras/alps/configure.m4, the variable "with_alps" gets set and the
"$1_CPPFLAGS=..." is then unreachable when the ORTE_CHECK_ALPS macro is run
later from config/orte_check_alps.m4.
Though it leaves the indentation sloppy, I believe the following might fix
the problem, but I lack the autotools versions to test this myself:
--- config/orte_check_alps.m4 (revision 27954)
+++ config/orte_check_alps.m4 (working copy)
@@ -80,6 +80,7 @@
[orte_check_alps_dir="/opt/cray/alps/default"],
[orte_check_alps_dir="$with_alps"])
fi
+ fi
$1_CPPFLAGS="-I$orte_check_alps_dir/include"
$1_LDFLAGS="-L$orte_check_alps_libdir"
@@ -106,7 +107,6 @@
AC_MSG_ERROR([Cannot continue])])
fi
fi
- fi
fi
AS_IF([test "$orte_check_alps_happy" = "yes"],
-Paul
On Mon, Jan 28, 2013 at 6:30 PM, Ralph Castain <r...@open-mpi.org> wrote:
> Like I said, I didn't write this code - all I can say for certain is that
> it gets the right answer on the LANL Crays. I'll talk to Nathan (the
> author) about it tomorrow.
>
> On Jan 28, 2013, at 6:23 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
>
> Ralph writes
>
>> ?? It looks correct to me - if with_alps is "yes", then no path was given
>> and we have to look at a default location. If it isn't yes, then a path was
>> given and we use it.
>> Am I missing something?
>
>
> Maybe *I* am the one missing something, but the way I read it the
> following defaults are applied
>
> CLE4:
> orte_check_alps_libdir="/usr/lib/alps"
> orte_check_alps_dir="/opt/cray/alps/default"
> CLE5:
> orte_check_alps_libdir="/opt/cray/alps/default/lib64"
> orte_check_alps_dir="/usr"
>
> Unless I am mistaken, the defaults for orte_check_alps_dir should be
> exchanged to yield:
>
> CLE4:
> orte_check_alps_libdir="/usr/lib/alps"
> orte_check_alps_dir="/usr"
> CLE5:
> orte_check_alps_libdir="/opt/cray/alps/default/lib64"
> orte_check_alps_dir="/opt/cray/alps/default"
>
> -Paul
>
>
> On Mon, Jan 28, 2013 at 6:14 PM, Ralph Castain <r...@open-mpi.org> wrote:
>
>>
>> On Jan 28, 2013, at 6:10 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
>>
>> The following 2 fragment from config/orte_check_alps.m4 appear to be
>> contradictory.
>> By that I mean the first appears to mean that "--with-alps" with no
>> argument means /opt/cray/alps/default/... for CLE5 and /usr/... for CLE4,
>> while the second fragment appears to be doing the opposite:
>>
>> if test "$using_cle5_install" = "yes"; then
>>
>> orte_check_alps_libdir="/opt/cray/alps/default/lib64"
>> else
>> orte_check_alps_libdir="/usr/lib/alps"
>> fi
>>
>>
>> if test "$using_cle5_install" = "yes" ; then
>> AS_IF([test "$with_alps" = "yes"],
>> [orte_check_alps_dir="/usr"],
>> [orte_check_alps_dir="$with_alps"])
>> else
>> AS_IF([test "$with_alps" = "yes"],
>> [orte_check_alps_dir="/opt/cray/alps/default"],
>> [orte_check_alps_dir="$with_alps"])
>> fi
>>
>> At least based on header and lib locations on NERSC's XC30 (CLE 5.0.15)
>> and XE6 (CLE 4.1.40), the first fragment is correctwhile the second
>> fragment is "backwards" (the two calls to AS_IF should be exchanged, or the
>> initial "test" should be inverted).
>>
>>
>> ?? It looks correct to me - if with_alps is "yes", then no path was given
>> and we have to look at a default location. If it isn't yes, then a path was
>> given and we use it.
>>
>> Am I missing something?
>>
>>
>> Note this same logic is present in both trunk and v1.7 (in SVN - I am not
>> looking at tarballs this time).
>>
>> -Paul
>>
>>
>>
>>
>>
>>
>> --
>> Paul H. Hargrove phhargr...@lbl.gov
>> Future Technologies Group
>> Computer and Data Sciences Department Tel: +1-510-495-2352
>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Paul H. Hargrove phhargr...@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> _______________________________________________
> 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
>
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
