Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] MPICH2 question
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2009-10-20 17:32:38


Jeff Squyres wrote:
> Pavan and I chatted on the phone this morning about
> https://svn.open-mpi.org/trac/hwloc/ticket/4.
>
> The *easiest* solution for MPICH2 would be if they could
> AC_CONFIG_SUBDIRS our configure script. However, this has the
> condition that hwloc's configure could never fail -- e.g., it can't
> call AC_MSG_ERROR. For unsupported platforms, it will need to still
> succeed and build/install a token libhwloc.la. This libhwloc.a can
> just return a graceful failure from hwloc_init() at run-time
> indicating that it can't do anything on this platform.
>
> By default, I'm not comfortable with this. But I would be comfortable
> with such a scheme if a non-default flag is passed to configure (e.g.,
> "--enable-always-build", or perhaps a better name).
>
> Would this be hard to do from the building side? I.e., I have not
> looked in the C code much yet -- do we have much code that won't build
> on unsupported platforms, or do we need a "generic / always fail" .c
> file that is trivial/portable C, but always returns failures for all
> hwloc API functions...?

>From my quick tests, if you try to build on a non-supported platform,
you'll probably get a System object with 1 or N processors depending on
whether sysconf is available. So building the topology looks ok. And you
get -1 and ENOSYS if you try to bind.

I am not sure how hard it'd be to avoid errors during configure. Are we
sure PKG_* macros or other external things will never use AC_MSG_ERROR ?

Brice