> On Nov. 2, 2016, 10:32 a.m., Benjamin Bannier wrote:
> > 3rdparty/libprocess/m4/ax_check_compile_flag.m4, line 1
> > <https://reviews.apache.org/r/52695/diff/4/?file=1551008#file1551008line1>
> >
> > For future updates it would be great if we'd write down the
> > autoconf-archive release this file came from (it looks like the latest
> > release containing it is `v2016.09.16`).
>
> Aaron Wood wrote:
> I don't see any of the other macros having this information. Would you
> just prefer a comment at the very top indicating the release?
> I took this from HEAD a few weeks back from this location
> http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_compile_flag.m4
> How can you tell it's from `v2016.09.16`?
>
> Benjamin Bannier wrote:
> Yes, currently this doesn't exist in many places, but I think it would be
> great to at least mention to upstream commit SHA1 you took this from, e.g.,
> in this commit message. This can potentially make applying new upstream
> version of this file easier should we ever patch it.
>
> What I did to tell what release this was is in is to checkout the
> upstream repo, and find which version it matched (`HEAD`). This can become
> harder if we patch the file substantially, or upstream reorganizes their code.
You marked this as resolved, but I couldn't find the change. Could you please
update e.g., the commit message to include something like
This commit adds ax_check_compiler_flag.m4 from
git://git.sv.gnu.org/autoconf-archive.git tag v2016.09.16.
- Benjamin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52695/#review154527
-----------------------------------------------------------
On Nov. 8, 2016, 6:41 p.m., Aaron Wood wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52695/
> -----------------------------------------------------------
>
> (Updated Nov. 8, 2016, 6:41 p.m.)
>
>
> Review request for mesos, James Peach, Michael Park, and Neil Conway.
>
>
> Bugs: MESOS-6229
> https://issues.apache.org/jira/browse/MESOS-6229
>
>
> Repository: mesos
>
>
> Description
> -------
>
> Use a default set of flags to provide additional security and hardening to
> libprocess. Additionally, check and catch more warnings/errors.
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/Makefile.am 7131989
> 3rdparty/libprocess/configure.ac e65e5ca
> 3rdparty/libprocess/m4/ax_check_compile_flag.m4 PRE-CREATION
>
> Diff: https://reviews.apache.org/r/52695/diff/
>
>
> Testing
> -------
>
> Compared the benchmarks with and without the flags being used. Also did a
> comparsion with the flags being used with and without optimizations and
> without the flags being used with and without optimizations. Overall the
> performance hit was very small with a 3-8% overhead (optimizations brings
> this down slightly). Most benchmarks were about 5% (or less) slower.
>
>
> File Attachments
> ----------------
>
> --enable-optimized with hardening applied
>
> https://reviews.apache.org/media/uploaded/files/2016/11/02/875c9e6e-c73b-4e3c-8265-0f7c6dc00351__hardened-optimized.txt
> Hardening applied but no --enable-optimized
>
> https://reviews.apache.org/media/uploaded/files/2016/11/02/932d28a7-2d31-471a-b438-647841a6853c__hardened-unoptimized.txt
> --enable-optimized with no hardening applied
>
> https://reviews.apache.org/media/uploaded/files/2016/11/02/896944ea-9b31-4d62-b1b9-97fb4700a882__optimized.txt
> No hardening applied and no --enable-optimized
>
> https://reviews.apache.org/media/uploaded/files/2016/11/02/b32667ce-3e3b-4d2b-b4f8-4c2404a0fc1c__unoptimized.txt
>
>
> Thanks,
>
> Aaron Wood
>
>
