Agreed. Using the old SWIG trick and use a less strict environment for
some external dependencies (e.g., ProtoBuf) seems like the right thing
to do. Thanks for looking into this! I would've done it myself if I had
a better understanding of the build system.

Most of the issues I have run into were related to specific protobuf
versions. I believe protobuf 3.3.0 had some issues with some headers
referring to undefined macros. Some other, older versions (2.6.1 or
2.4.1), triggered a misleading indentation warning.

Maybe the right solution is to not treat warnings as errors for protobuf
sources?

Thanks,
Andreas


On 21/03/2018 22:00, Gabe Black wrote:
I definitely don't think we should disable -Wall or -Werror. I'll look into
ways to disable that check in specific cases. Surprisingly I haven't run
into this problem on my workstation even though I've hit a bunch of other
problems related to very up to date tool versions, but maybe it's just
because I usually use gcc and not clang? I might need some help to make
sure any potential fix actually fixes things.

Gabe

On Wed, Mar 21, 2018 at 9:29 AM, Matthias Jung <jun...@eit.uni-kl.de> wrote:

Hey,

by the way, when we talk about protobuf, I recently found this:

         https://capnproto.org

Its claimed, that capnproto is faster than protobuf,
However, I cannot confirm that because I have not tried it.

Has somebody else experience with capnproto?

Best,
Matthias

Am 21.03.2018 um 16:37 schrieb Matteo Andreozzi <
matteo.andreo...@arm.com>:
Hi Andreas,
Thanks for sending this out. I’ve been experiencing issues on Mac using
clang, the issue in detail is:
Scons tries to build a test program including message.h from protobuf to
check if the protobuf C libraries are present
Protobuf versions later than 3.3.0 use the LANG_CXX11 macro without
defining it first, in at least one of their files (atom.h).
This causes the compilation of the test program to fail , due to the
-Wundef directive being set, and scons assuming that no protobuf is
available in the system.
The quick and dirty fix which I have on my local workspace is to remove
-Wundef from Sconstruct, which anyway never triggered before with the
exception of protobuf (on MSC_VER in the past, now on LANG_CXX11), see
below:
     main.Append(CCFLAGS=['-fno-strict-aliasing'])
     # Enable -Wall and -Wextra and then disable the few warnings that
     # we consistently violate
-    main.Append(CCFLAGS=['-Wall', '-Wundef', '-Wextra',
+    main.Append(CCFLAGS=['-Wall', '-Wextra',
                          '-Wno-sign-compare', '-Wno-unused-parameter'])
     # We always compile using C++11
     main.Append(CXXFLAGS=['-std=c++11'])


From: Andreas Sandberg <andreas.sandb...@arm.com>
Date: Wednesday, 21 March 2018 at 15:25
To: gem5 Developer List <gem5-dev@gem5.org>
Cc: Gabe Black <gabebl...@google.com>, Matteo Andreozzi <
matteo.andreo...@arm.com>
Subject: Protobuf compilation errors

Hi Everyone,

We have been experiencing some issues with some combinations of
different versions of protobuf and gcc/clang. Most of the issues seem to
be related to undefined macros (-Wundef), but I have some vague memories
of other issues as well (unclear indentation?).

In the short term, it seems like we need to disable -Werror for files
that are generated by protoc. Another option would be to add
-Wno-error=undef to the global environment. What would be the preferred
solution here? I think I'm in favour of the former, but don't understand
the build system well enough to implement it.

Cheers,
Andreas


IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to