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