lttng-dev.lists.lttng.org archive mirror
 help / color / mirror / Atom feed
From: Rocky Dunlap via lttng-dev <lttng-dev@lists.lttng.org>
To: Simon Marchi <simark@simark.ca>
Cc: lttng-dev@lists.lttng.org
Subject: Re: Babeltrace2 - compilation error with intel18
Date: Mon, 23 Mar 2020 11:37:51 -0600	[thread overview]
Message-ID: <CADtyBo7ZL2bGqwq5V7Xg7JWSQfndj13TtaOD5tQctB1W1uNWpQ@mail.gmail.com> (raw)
In-Reply-To: <45822fa3-e680-4946-5919-27b4b5398988@simark.ca>


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

Simon,

See below...

On Mon, Mar 23, 2020 at 11:24 AM Simon Marchi <simark@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
> >
>
>

[-- Attachment #1.2: Type: text/html, Size: 4638 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

      reply	other threads:[~2020-03-23 17:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-20 21:10 Babeltrace2 - compilation error with intel18 Rocky Dunlap via lttng-dev
2020-03-20 21:47 ` Simon Marchi via lttng-dev
2020-03-20 21:55   ` Rocky Dunlap via lttng-dev
2020-03-20 22:20     ` Simon Marchi via lttng-dev
2020-03-20 22:32       ` Rocky Dunlap via lttng-dev
2020-03-21  3:12         ` Simon Marchi via lttng-dev
2020-03-23 15:44           ` Simon Marchi via lttng-dev
2020-03-23 16:05             ` Rocky Dunlap via lttng-dev
2020-03-23 16:14               ` Simon Marchi via lttng-dev
2020-03-23 16:56                 ` Rocky Dunlap via lttng-dev
2020-03-23 17:24                   ` Simon Marchi via lttng-dev
2020-03-23 17:37                     ` Rocky Dunlap via lttng-dev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADtyBo7ZL2bGqwq5V7Xg7JWSQfndj13TtaOD5tQctB1W1uNWpQ@mail.gmail.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=dunlap@ucar.edu \
    --cc=simark@simark.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).