[1.61.0] building with Clang and c++11
I have downloaded 1.61.0 and want to build it with Clang. This is in my user-config:
using clang : 3.5.0 : /netDISKS/master/netmt/LINUX_C65/app/clang/3.5.0/bin/clang++ : <compileflags>"-fPIC -gcc-toolchain /netDISKS/master/netmt/LINUX_C65/app/gcc/4.8.3 -Wno-overloaded-virtual -Wno-unused-function -Wno-unused-variable -Wno-c99-extensions -Wno-variadic-macros" <linkflags>"-fPIC -gcc-toolchain /netDISKS/master/netmt/LINUX_C65/app/gcc/4.8.3" ;
When I build, I see warnings like these:
./boost/mpl/print.hpp:50:19: warning: in-class initialization of non-static data member is a C++11 extension [-Wc++11-extensions]
const int m_x = 1 / (sizeof(T) - sizeof(T));
^
./boost/timer/timer.hpp:44:43: warning: 'long long' is a C++11 extension [-Wc++11-long-long]
void clear() { wall = user = system = 0LL; }
^
./boost/regex/v4/instances.hpp:124:34: warning: unknown warning group '-Wkeyword-macro', ignored [-Wunknown-pragmas]
#pragma clang diagnostic ignored "-Wkeyword-macro"
^
When I add '-std=c++11' to the <compileflags> and <linkflags>, I get errors and warnings like these:
clang-linux.compile.c.without-pth bin.v2/libs/container/build/clang-linux-3.5.0/release/instruction-set-core2/link-static/threading-multi/alloc_lib.o
error: invalid argument '-std=c++11' not allowed with 'C/ObjC'
"/netDISKS/master/netmt/LINUX_C65/app/clang/3.5.0/bin/clang++" -c -x c -O3 -Wno-inline -Wall -std=c++11 -fPIC -gcc-toolchain /netDISKS/master/netmt/LINUX_C65/app/gcc/4.8.3 -Wno-overloaded-virtual -Wno-unused-function -Wno-unused-variable -Wno-c99-extensions -Wno-variadic-macros -march=core2 -pthread -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTAINER_STATIC_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/container/build/clang-linux-3.5.0/release/instruction-set-core2/link-static/threading-multi/alloc_lib.o" "libs/container/src/alloc_lib.c"
libs/locale/src/shared/localization_backend.cpp:54:22: warning: 'auto_ptr' is deprecated [-Wdeprecated-declarations]
std::auto_ptr
Richard, for context, I don't think Boost C++ Libraries can be expected to build without warnings on any compiler these days. There are just too many versions of compilers producing warnings in too many ingenious ways. On 30-Jun-16 11:32 PM, Richard Hadsell wrote:
I have downloaded 1.61.0 and want to build it with Clang. This is in my user-config:
using clang : 3.5.0 : /netDISKS/master/netmt/LINUX_C65/app/clang/3.5.0/bin/clang++ : <compileflags>"-fPIC -gcc-toolchain /netDISKS/master/netmt/LINUX_C65/app/gcc/4.8.3 -Wno-overloaded-virtual -Wno-unused-function -Wno-unused-variable -Wno-c99-extensions -Wno-variadic-macros" <linkflags>"-fPIC -gcc-toolchain /netDISKS/master/netmt/LINUX_C65/app/gcc/4.8.3" ;
When I build, I see warnings like these:
./boost/mpl/print.hpp:50:19: warning: in-class initialization of non-static data member is a C++11 extension [-Wc++11-extensions] const int m_x = 1 / (sizeof(T) - sizeof(T)); ^ ./boost/timer/timer.hpp:44:43: warning: 'long long' is a C++11 extension [-Wc++11-long-long] void clear() { wall = user = system = 0LL; } ^ ./boost/regex/v4/instances.hpp:124:34: warning: unknown warning group '-Wkeyword-macro', ignored [-Wunknown-pragmas] #pragma clang diagnostic ignored "-Wkeyword-macro"
The warnings above mention the command-line options that will silence the warnings. E.g. if you pass -Wno-keyword-macro, the last warning should go away. Likewise for other warnings. You might consider reporting these warnings to libraries developers.
When I add '-std=c++11' to the <compileflags> and <linkflags>, I get errors and warnings like these:
clang-linux.compile.c.without-pth bin.v2/libs/container/build/clang-linux-3.5.0/release/instruction-set-core2/link-static/threading-multi/alloc_lib.o
error: invalid argument '-std=c++11' not allowed with 'C/ObjC'
Seems like clang is unnecessary pedantic here. Though, I don't know why container includes .c files - might be worth raising an issue too. So, the bottom line is that you either have to live with the warnings, or disable them with '-Wno-*' options. HTH, Volodya
On Fri, 1 Jul 2016 at 04:56 Vladimir Prus
Richard,
for context, I don't think Boost C++ Libraries can be expected to build without warnings on any compiler these days. There are just too many versions of compilers producing warnings in too many ingenious ways.
<snip>
The warnings above mention the command-line options that will silence the warnings. E.g. if you pass -Wno-keyword-macro, the last warning should go away. Likewise for other warnings. You might consider reporting these warnings to libraries developers.
<snip>
Seems like clang is unnecessary pedantic here. Though, I don't know why container includes .c files - might be worth raising an issue too.
So, the bottom line is that you either have to live with the warnings, or disable them with '-Wno-*' options.
For building boost itself, I suggest just living with and ignoring the warnings. For consuming boost, I find including boost via -isystem, instead of -I, useful because I generally don't care about warnings from boost, but might not want to silence them entirely, or live with them, in my project. -- chris
On 07/01/2016 09:36 AM, Chris Glover wrote:
On Fri, 1 Jul 2016 at 04:56 Vladimir Prus
wrote: for context, I don't think Boost C++ Libraries can be expected to build without warnings on any compiler these days. There are just too many versions of compilers producing warnings in too many ingenious ways. The warnings above mention the command-line options that will silence the warnings. E.g. if you pass -Wno-keyword-macro, the last warning should go away. Likewise for other warnings. You might consider reporting these warnings to libraries developers. Seems like clang is unnecessary pedantic here. Though, I don't know why container includes .c files - might be worth raising an issue too.
So, the bottom line is that you either have to live with the warnings, or disable them with '-Wno-*' options. For building boost itself, I suggest just living with and ignoring the warnings.
For consuming boost, I find including boost via -isystem, instead of -I, useful because I generally don't care about warnings from boost, but might not want to silence them entirely, or live with them, in my project. I understand, and I have added warning suppressions for those that seem harmless. I may just use -isystem for using the libraries in our code.
I was mostly concerned by the warnings, when not using -std=c++11: 'long long' and 'in-class initialization of non-static data member'. I can't tell whether Clang supports them as extensions or whether it ignores them. But when I use -std=c++11 I get an error on a C file, which I think means the library does not build correctly. I'll report that separately, as Vladimir suggests. -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell@blueskystudios.com Blue Sky Studioshttp://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560
Richard Hadsell wrote:
./boost/mpl/print.hpp:50:19: warning: in-class initialization of non-static data member is a C++11 extension [-Wc++11-extensions] const int m_x = 1 / (sizeof(T) - sizeof(T));
I confirmed that including
./boost/regex/v4/instances.hpp:124:34: warning: unknown warning group '-Wkeyword-macro', ignored [-Wunknown-pragmas] #pragma clang diagnostic ignored "-Wkeyword-macro"
I'm not sure this is worth fixing, but we can remove the warning by #ifdef __has_warning #if __has_warning("-Wkeyword-macro") #pragma ... #endif #endif Regards, Michel
On 07/02/2016 07:45 AM, Michel Morin wrote:
I confirmed that including
on Clang in C++03 mode **always** produces a warning (i.e. even without using `boost::mpl::print<T>`). IMHO this issue should be fixed, so I made a PR
A simpler patch is to make m_x static.
You can easily verify that this works with BOOST_STATIC_WARNING() from
Bjorn Reese wrote:
A simpler patch is to make m_x static.
That would produce a compilation error: `1 / 0` is not a constant expression. The downside of using non-static data member is that `mpl::print` no longer gives warning with a typedef `typedef mpl::print<Foo> X;`. We need a variable `mpl::print<Foo> x;` to produce warning. The "deprecated" attribute might be a better way to produce warning. But I fail to apply that attribute to class templates. Regards, Michel
participants (5)
-
Bjorn Reese
-
Chris Glover
-
Michel Morin
-
Richard Hadsell
-
Vladimir Prus