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
> <[email protected]> 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
>
> [email protected] 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
> [email protected]
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
