<div dir="ltr">Simon,<div><br></div><div>I was able to get past the issue by passing "--enable-compile-warnings=yes" to configure.</div><div><br></div><div>It get a lot further, then fails here:</div><div><br></div><div>gcc -pthread -shared -L/apps/intel/intelpython3/lib -Wl,-rpath=/apps/intel/intelpython3/lib,--no-as-needed -Wl,-z,noexecstack,-z,relro,-z,now -L../../../../src/lib/.libs -pthread -lgmodule-2.0 -lglib-2.0 -pthread -lgmodule-2.0 -lglib-2.0 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fno-strict-aliasing -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -Wdeclaration-after-statement -Wimplicit-function-declaration -Wold-style-definition -Wjump-misses-init -Wall -Wextra -Wundef -Wwrite-strings -Wpointer-arith -Wmissing-declarations -Wredundant-decls -Wno-unused-parameter -Wno-missing-field-initializers -Wformat=2 -Wcast-align -Wformat-nonliteral -Wformat-security -Wsign-compare -Wstrict-aliasing -Wshadow -Winline -Wpacked -Wmissing-format-attribute -Wmissing-noreturn -Winit-self -Wmissing-include-dirs -Wunused-but-set-variable -Warray-bounds -Wreturn-type -Wswitch-enum -Wswitch-default -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict -Wnull-dereference -Wdouble-promotion -Wno-sign-compare -Wno-inline -Wno-declaration-after-statement -Wno-switch-enum -Wno-switch-default -Wno-packed -Wno-pointer-arith -Wno-format-nonliteral -Wno-double-promotion -Wno-cast-align -Wno-cast-function-type -Wno-error=unused-parameter -Wno-error=missing-field-initializers -Wno-error=sign-compare -Wno-error=inline -Wno-error=declaration-after-statement -Wno-error=switch-enum -Wno-error=switch-default -Wno-error=packed -Wno-error=pointer-arith -Wno-error=format-nonliteral -Wno-error=double-promotion -Wno-error=cast-align -Wno-error=cast-function-type -Wold-style-definition -Werror=implicit-function-declaration -g -O2 -Wno-shadow -Wno-null-dereference -I../../../../include -I../../../../src -I../../../../src -include common/config.h -I./bt2 build/temp.linux-x86_64-3.6/bt2/native_bt.o build/temp.linux-x86_64-3.6/./bt2/logging.o ../../../../src/autodisc/.libs/libbabeltrace2-autodisc.a ../../../../src/logging/.libs/libbabeltrace2-logging.a ../../../../src/common/.libs/libbabeltrace2-common.a ../../../../src/py-common/.libs/libbabeltrace2-py-common.a ../../../../src/string-format/.libs/libbabeltrace2-string-format.a -L/apps/intel/intelpython3/lib -lbabeltrace2 -lglib-2.0 -lpython3.6m -o build/build_lib/bt2/_<a href="http://native_bt.cpython-36m-x86_64-linux-gnu.so">native_bt.cpython-36m-x86_64-linux-gnu.so</a><br>gcc: error: unrecognized command line option ‘-Wduplicated-cond’<br>gcc: error: unrecognized command line option ‘-Wduplicated-branches’<br>gcc: error: unrecognized command line option ‘-Wrestrict’<br>gcc: error: unrecognized command line option ‘-Wnull-dereference’<br>error: command 'gcc' failed with exit status 1<br>make[4]: *** [build-python-bindings.stamp] Error 1<br></div><div><br></div><div>I am surprised that this is using "gcc" here, shouldn't it be using "icc" since I have CC=icc?<br></div><div><br></div><div>Or maybe it is supposed to be using gcc?  I think if I update the GCC compiler version then it will get past this issue as well, but I just wanted confirmation that this indeed should be using a combination of gcc and icc?</div><div><br></div><div>If it should be icc, can you point me to where in the configure/make system I can make this change to force it to use what's sets as CC instead of defaulting to GCC?</div><div><br></div><div>Rocky</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 20, 2020 at 3:47 PM Simon Marchi <<a href="mailto:simark@simark.ca">simark@simark.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-03-20 5:10 p.m., Rocky Dunlap via lttng-dev wrote:<br>
> I am trying to compile BT2 with Python bindings using Intel18.  I receive the following error during the build:<br>
Hi Rocky,<br>
<br>
I don't think we claim to support the Intel compiler, so you might be a bit<br>
on your own here.  Although if you want to send patches to fix the build using<br>
that compiler, I don't have anything against that.<br>
<br>
> <br>
> In file included from py-common.c(31):<br>
> /apps/intel/intelpython3/include/python3.6m/Python.h(149): error #193: zero used for undefined preprocessing identifier "_MSC_VER"<br>
>   #if _MSC_VER<br>
>       ^<br>
> <br>
> In file included from py-common.c(31):<br>
> /apps/intel/intelpython3/include/python3.6m/Python.h(151): error #193: zero used for undefined preprocessing identifier "__clang__"<br>
>   #elif __clang__ || __GNUC__<br>
>         ^<br>
<br>
It took me a bit of time to understand that this is Intel's Python 3<br>
distribution, not CPython.<br>
<br>
I think it's technically valid to use an undefined macro in a preprocessor<br>
condition like that, in which case it gets replaced with 0 (as the error<br>
message mentions).  The compiler is trying to be helpful and warns you, because<br>
relying on that behavior is a bit fragile, and often a sign of a mistake<br>
somewhere.  But since this happens in a library you are using, I think your best<br>
bet is just to disable this warning.<br>
<br>
> py-common.c(187): error #3179: deprecated conversion of string literal to char* (should be const char*)<br>
>   format_exc_func_name = py_exc_tb ? "format_exception" :<br>
<br>
I really don't understand this one, as format_exc_func_name is a const char *<br>
in our code.<br>
<br>
Simon<br>
<br>
</blockquote></div>