Re: Babeltrace2 - compilation error with intel18

[Rocky Dunlap via lttng-dev <lttng-dev@lists.lttng.org>]

[-- Attachment #1.1: Type: text/plain, Size: 5242 bytes --]

Simon,

I was able to get past the issue by passing "--enable-compile-warnings=yes"
to configure.

It get a lot further, then fails here:

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/_native_bt.cpython-36m-x86_64-linux-gnu.so
gcc: error: unrecognized command line option ‘-Wduplicated-cond’
gcc: error: unrecognized command line option ‘-Wduplicated-branches’
gcc: error: unrecognized command line option ‘-Wrestrict’
gcc: error: unrecognized command line option ‘-Wnull-dereference’
error: command 'gcc' failed with exit status 1
make[4]: *** [build-python-bindings.stamp] Error 1

I am surprised that this is using "gcc" here, shouldn't it be using "icc"
since I have CC=icc?

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?

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?

Rocky

On Fri, Mar 20, 2020 at 3:47 PM Simon Marchi <simark@simark.ca> wrote:

> On 2020-03-20 5:10 p.m., Rocky Dunlap via lttng-dev wrote:
> > I am trying to compile BT2 with Python bindings using Intel18.  I
> receive the following error during the build:
> Hi Rocky,
>
> I don't think we claim to support the Intel compiler, so you might be a bit
> on your own here.  Although if you want to send patches to fix the build
> using
> that compiler, I don't have anything against that.
>
> >
> > In file included from py-common.c(31):
> > /apps/intel/intelpython3/include/python3.6m/Python.h(149): error #193:
> zero used for undefined preprocessing identifier "_MSC_VER"
> >   #if _MSC_VER
> >       ^
> >
> > In file included from py-common.c(31):
> > /apps/intel/intelpython3/include/python3.6m/Python.h(151): error #193:
> zero used for undefined preprocessing identifier "__clang__"
> >   #elif __clang__ || __GNUC__
> >         ^
>
> It took me a bit of time to understand that this is Intel's Python 3
> distribution, not CPython.
>
> I think it's technically valid to use an undefined macro in a preprocessor
> condition like that, in which case it gets replaced with 0 (as the error
> message mentions).  The compiler is trying to be helpful and warns you,
> because
> relying on that behavior is a bit fragile, and often a sign of a mistake
> somewhere.  But since this happens in a library you are using, I think
> your best
> bet is just to disable this warning.
>
> > py-common.c(187): error #3179: deprecated conversion of string literal
> to char* (should be const char*)
> >   format_exc_func_name = py_exc_tb ? "format_exception" :
>
> I really don't understand this one, as format_exc_func_name is a const
> char *
> in our code.
>
> Simon
>
>

[-- Attachment #1.2: Type: text/html, Size: 5914 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev