Ralph,

do you use VPATH ?

can you give a try to the patch below ?

Cheers,

Gilles

diff --git a/opal/mca/hwloc/hwloc1113/configure.m4
b/opal/mca/hwloc/hwloc1113/configure.m4

index 7fe3527..c1646d4 100644

--- a/opal/mca/hwloc/hwloc1113/configure.m4

+++ b/opal/mca/hwloc/hwloc1113/configure.m4

@@ -52,9 +52,9 @@ AC_DEFUN([MCA_opal_hwloc_hwloc1113_POST_CONFIG],[

            # Add some stuff to CPPFLAGS so that the rest of the source

            # tree can be built

            file=$opal_hwloc_hwloc1113_basedir/hwloc

-           CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_SRCDIR/$file/include"

            AS_IF([test "$OPAL_TOP_BUILDDIR" != "$OPAL_TOP_SRCDIR"],

-                 [CPPFLAGS="$CPPFLAGS -I$OPAL_TOP_BUILDDIR/$file/include"])

+                 [CPPFLAGS="-I$OPAL_TOP_BUILDDIR/$file/include $CPPFLAGS"])

+           CPPFLAGS="-I$OPAL_TOP_SRCDIR/$file/include $CPPFLAGS"

            unset file

           ])

     OPAL_VAR_SCOPE_POP

diff --git a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4
b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4

index 6807624..3f6a6fe 100644

--- a/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4

+++ b/opal/mca/hwloc/hwloc1113/hwloc/config/hwloc.m4

@@ -988,7 +988,7 @@ EOF])

     if test "x$enable_cpuid" != "xno"; then

        AC_MSG_CHECKING([for x86 cpuid])

        old_CPPFLAGS="$CPPFLAGS"

-       CPPFLAGS="$CPPFLAGS -I$HWLOC_top_srcdir/include"

+       CPPFLAGS="-I$HWLOC_top_srcdir/include $CPPFLAGS"

        # We need hwloc_uint64_t but we can't use
hwloc/autogen/config.h before configure ends.

        # So pass #include/#define manually here for now.

        CPUID_CHECK_HEADERS=


On Thu, Sep 22, 2016 at 10:13 PM, r...@open-mpi.org <r...@open-mpi.org> wrote:
> Here is the compile line:
>
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../opal/include
> -I../../ompi/include -I../../oshmem/include
> -I../../opal/mca/hwloc/hwloc1113/hwloc/include/private/autogen
> -I../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc/autogen
> -I../../ompi/mpiext/cuda/c -I../.. -I../../orte/include
> -I/Users/rhc/local/include
> -I/Users/rhc/openmpi/foobar/opal/mca/hwloc/hwloc1113/hwloc/include
> -I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent
> -I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent/include
> -L/Users/rhc/local/lib -g -Wall -Wundef -Wno-long-long -Wsign-compare
> -Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic
> -Werror-implicit-function-declaration -finline-functions
> -fno-strict-aliasing -mcx16 -MT proc.lo -MD -MP -MF .deps/proc.Tpo -c proc.c
> -fno-common -DPIC -o .libs/proc.o
> depbase=`echo qsort.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
>         /bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
> -I. -I../../opal/include -I../../ompi/include -I../../oshmem/include
> -I../../opal/mca/hwloc/hwloc1113/hwloc/include/private/autogen
> -I../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc/autogen
> -I../../ompi/mpiext/cuda/c   -I../.. -I../../orte/include
> -I/Users/rhc/local/include
> -I/Users/rhc/openmpi/foobar/opal/mca/hwloc/hwloc1113/hwloc/include
> -I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent
> -I/Users/rhc/openmpi/foobar/opal/mca/event/libevent2022/libevent/include
> -L/Users/rhc/local/lib -g -Wall -Wundef -Wno-long-long -Wsign-compare
> -Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic
> -Werror-implicit-function-declaration -finline-functions
> -fno-strict-aliasing -mcx16  -MT qsort.lo -MD -MP -MF $depbase.Tpo -c -o
> qsort.lo qsort.c &&\
>
>
> It looks to me like my CPPFLAGS are stuck in the middle of the whole mess -
> I wonder if that’s the problem? I see it sandwiched in-between flags for
> different levels of hwloc redirection
>
>
> On Sep 22, 2016, at 4:40 AM, Gilles Gouaillardet
> <gilles.gouaillar...@gmail.com> wrote:
>
> Ralph,
>
> Is the root cause we append our stuff to CPPFLAGS, instead of prepend ?
>
> You can retrieve the compile command line with
> make V=1
>
> If my guess is correct, does someone know the rationale for append vs
> prepend ?
>
> Cheers,
>
> Gilles
>
> r...@open-mpi.org wrote:
> Hey folks
>
> I’m encountering an issue with the way we detect external HWLOC. If I have a
> directory that includes an hwloc installation in my CPPFLAGS, then we fail
> to build, even if I don’t specify anything with regard to hwloc on my
> configure cmd line. The errors I get look like:
>
> In file included from sec_basic.c:11:0:
> ../../../../opal/include/opal_config.h:1348:0: note: this is the location of
> the previous definition
>  #define HWLOC_SYM_PREFIX opal_hwloc1113_
>  ^
> In file included from
> ../../../../opal/mca/hwloc/hwloc1113/hwloc/include/hwloc.h:53:0,
>                  from ../../../../opal/mca/hwloc/hwloc1113/hwloc1113.h:24,
>                  from ../../../../opal/mca/hwloc/hwloc.h:131,
>                  from ../../../../opal/util/proc.h:21,
>                  from ../../../../opal/mca/sec/sec.h:25,
>                  from ../../../../opal/mca/sec/base/base.h:23,
>                  from sec_basic.c:22:
> /Users/rhc/local/include/hwloc/autogen/config.h:200:0: warning:
> "HWLOC_SYM_PREFIX_CAPS" redefined
>  #define HWLOC_SYM_PREFIX_CAPS HWLOC_
>  ^
> In file included from sec_basic.c:11:0:
> ../../../../opal/include/opal_config.h:1351:0: note: this is the location of
> the previous definition
>  #define HWLOC_SYM_PREFIX_CAPS OPAL_HWLOC1113_
>  ^
> Undefined symbols for architecture x86_64:
>   "_hwloc_bitmap_alloc", referenced from:
>       import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_and", referenced from:
>       import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_copy", referenced from:
>       import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_first", referenced from:
>       import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_free", referenced from:
>       import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_intersects", referenced from:
>       import-atom in libopen-pal.dylib
>   "_hwloc_bitmap_isincluded", referenced from:
> ...
>
> Lots and lots of repetitions of the warning from many different sources, and
> it’s clear that we somehow picked up the external header and went haywire.
> This isn’t what we intended to have happen - we are supposed to ignore
> external installations unless directed to use them.
>
> Is this the expected behavior? Any way we can clean this up?
> Ralph
>
> _______________________________________________
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Reply via email to