Yo Brian --
Do we need to bring this to v1.5, too?
On Feb 20, 2012, at 11:49 AM, Barrett, Brian W wrote:
> Hi Paul -
>
> Thanks for noticing this. I guess we don't have many Altix developers. I
> think I've fixed it on the trunk with r25968, plus r25967 to make sure the
> Altix component gets selected over the Linux component on Altix systems.
> I don't have an Altix to test on; can you give it a go and let me know if
> it works? In the trunk right now, and should be in the trunk nightly
> tarball tomorrow morning.
>
> The problem cropped up when we started running the configure macros for
> components that couldn't possibly succeed (which we needed to make
> Automake happy in a couple of situations) sometime late in the 1.5 series.
> Before that, a component could never think it succeeded and then later be
> told it didn't. We added yet another macro to handle issues like this, so
> it was a fairly easy fix.
>
> Thanks,
>
> Brian
>
> On 2/17/12 4:26 PM, "Paul H. Hargrove" <phhargr...@lbl.gov> wrote:
>
>>
>>
>>
>> I've poked enough at the ompi configure magic to *think* I
>> understand the source of the problem I've seen w/ both trunk and
>> 1.5.x on the Altix.
>>
>> The problem appears to be that both timer/altix/configure.m4 and
>> timer/linux/configure.m4 are setting the value of
>> $timer_base_include and the LAST one "wins". Meanwhile, only the
>> FIRST one is getting added to $static_components ("there can be only
>> one"). So, I suspect the difference I saw between trunk and 1.5 was
>> just a matter of which configure probe ran first.
>>
>> The result of having FIRST and LAST "win" in different settings is a
>> mismatch.
>>
>>
>> $ grep -e timer:linux -e timer:altix
>> configure.out
>> --- MCA component timer:linux (m4 configuration macro, priority
>> 30)
>> checking for MCA component timer:linux compile mode... static
>> checking if MCA component timer:linux can compile... yes
>> --- MCA component timer:altix (m4 configuration macro, priority
>> 30)
>> checking for MCA component timer:altix compile mode... static
>> checking if MCA component timer:altix can compile... no
>>
>>
>> which picks timer:linux and rejects timer:altix, as compared to:
>>
>>
>> $ grep -e '"MCA_opal_timer_[SD]' -e
>> MCA_timer_ config.status
>> S["MCA_opal_timer_DSO_SUBDIRS"]=""
>> S["MCA_opal_timer_STATIC_SUBDIRS"]=" mca/timer/linux"
>>
>> S["MCA_opal_timer_STATIC_LTLIBS"]="mca/timer/linux/libmca_timer_linux.la
>> "
>> S["MCA_opal_timer_DSO_COMPONENTS"]=""
>> S["MCA_opal_timer_STATIC_COMPONENTS"]=" linux"
>> D["MCA_timer_IMPLEMENTATION_HEADER"]="
>> \"opal/mca/timer/altix/timer_altix.h\""
>>
>>
>> Which will build timer:linux but has improperly picked up the
>> timer:altix HEADER!
>>
>>
>> For the present, an explicit --with-timer=altix works-around the
>> problem in either branch.
>> However, the setting of the header variable by a NON-selected
>> component is ERRONEOUS and should get fixed.
>> In trunk, it may also make sense to raise the priority of
>> timer:altix above that of timer:linux.
>>
>> -Paul
>>
>> On 2/15/2012 12:41 AM, Paul Hargrove wrote:
>>
>> I've configured the ompi trunk (nightly tarball 1.7a1r25927)
>> on an SGI Altix.
>> I used no special arguments indicating that this is an Altix,
>> and there does not appear to be an altix-specific file in
>> contrib/platform.
>>
>>
>> My build fails as follows:
>>
>>
>>
>>
>> make:
>> Entering directory
>> `/mnt/home/c_phargrov/OMPI/openmpi-trunk-linux-ia64/BLD/opal/tools/wrapper
>> s'
>> CC opal_wrapper.o
>> CCLD opal_wrapper
>> ../../../opal/.libs/libopen-pal.so: undefined reference to
>> `opal_timer_altix_mmdev_timer_addr'
>> ../../../opal/.libs/libopen-pal.so: undefined reference to
>> `opal_timer_altix_freq'
>> collect2: ld returned 1 exit status
>>
>>
>>
>>
>>
>>
>> The configure-generated opal_config.h contains
>> #define MCA_timer_IMPLEMENTATION_HEADER
>> "opal/mca/timer/altix/timer_altix.h"
>>
>>
>> Nothing appears to have been built in
>> BUILDDIR/opal/mca/timer/altix.
>> However, BUILDDIR/opal/mca/timer/linux has been built.
>>
>>
>> -Paul
>>
>>
>> --
>> Paul H. Hargrove phhargr...@lbl.gov
>> Future Technologies Group
>> HPC Research Department Tel: +1-510-495-2352
>> <tel:%2B1-510-495-2352>
>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> <tel:%2B1-510-486-6900>
>>
>>
>>
>>
>> --
>> Paul H. Hargrove phhargr...@lbl.gov
>> Future Technologies Group
>> HPC Research 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
>
>
> --
> 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/
