[lttng-dev] Babeltrace2 - compilation error with intel18

[Rocky Dunlap]

Simon,

See below...

On Mon, Mar 23, 2020 at 11:24 AM Simon Marchi <simark at simark.ca> wrote:

> On 2020-03-23 12:56 p.m., Rocky Dunlap wrote:
> > Simon,
> >
> > Success!  This change worked and I was able to build and install with
> icc.  Thank you!
>
> Ok, thanks.  Out of curiosity, did run a "make check"?  That would
> validate that
> the Python bindings (and everything else) works properly.
>

============================================================================
Testsuite summary for babeltrace2 2.1.0-rc1
============================================================================
# TOTAL: 21225
# PASS:  21225
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================



>
> > I still get a lot of warnings during the build (see below) which seems
> like configure should work these out ahead of time.  They are easy enough
> to ignore, but if support for intel is added, it would be nice to have
> these cleaned up.  For what it's worth, adding support for additional
> compilers in my experience has greatly improved the quality of library code
> - it tends to snuff out those bugs that are hard to find on a single
> compiler.
>
> I agree, that's why we want to keep babeltrace building with clang (on top
> of having to
> support macOS, on which clang is the default compiler).
>
> We use the AX_APPEND_COMPILE_FLAGS autoconf macro [1] to determine which
> warning flags
> the current compiler supports.  This calls the compiler with each flag
> individually
> to see if the compiler supports that flag.  This requires that the
> compiler errors
> out when passed an invalid flag.  Currently, it looks like icc emits a
> warning, but still
> returns exit code 0 when passed an invalid flag, so we end up enabling all
> of them.  Try
> to check in config.log to see what happens currently.  For example here
> are the test
> results for two flags, one supported and one not supported by clang:
>
> 4625 configure:17825: checking whether C compiler accepts -Winit-self
> 4626 configure:17844: ccache clang -c -gdwarf-5 -g3 -O2 -fsanitize=address
> -Werror -Winit-self  conftest.c >&5
> 4627 configure:17844: $? = 0
> 4628 configure:17853: result: yes
> 4629 configure:17869: : WARN_CFLAGS="$WARN_CFLAGS"
> 4630 configure:17872: $? = 0
> 4631 configure:17825: checking whether C compiler accepts -Wduplicated-cond
> 4632 configure:17844: ccache clang -c -gdwarf-5 -g3 -O2 -fsanitize=address
> -Werror -Wduplicated-cond  conftest.c >&5
> 4633 error: unknown warning option '-Wduplicated-cond'; did you mean
> '-Wduplicate-enum'? [-Werror,-Wunknown-warning-option]
> 4634 configure:17844: $? = 1
>
> If you can come up with the right incantation to make that work well with
> icc, we
> can modify how we call the macro or modify the macro itself (sending a
> patch to
> the upstream, Autoconf Archive).
>
> [1]
> https://www.gnu.org/software/autoconf-archive/ax_append_compile_flags.html


Okay, I'll try to find some time look into this.



>
>
> > If you decide to merge this in, a release patch 2.0.3 would certainly be
> helpful as well!
>
> Things have started to diverge a bit between master and the 2.0 branch,
> I'm not sure if we'll
> be able to backport that, we'll see.
>

Sure, no problem.  I'm not sure what the overall release schedule is, so
maybe it would be a 2.1 at some point soon?


>
> Simon
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20200323/f2231010/attachment-0001.htm>