I am facing the weirdest thing ever. I am having a deprecation warning although I am using -Wno-deprecated flag with g++.
What am I doing wrong? Should I reorder the flags I am passing to g++?
g++ -fno-strict-aliasing -Wall -D__LINUX__ -DOS_USE_STD_IOSTREAMS -DOS_LINUX_2_2 -D__CPP -D__USE_BSD -DLINUX -Wno-sign-compare -Wno-deprecated -Wno-unused-variable -Wno-write-strings -Wno-unused -DOS_USE_STD_IOSTREAM -m64 -m64 -O3 -Werror
The deprecation warning is specifically about sys_errlist and that I should use stderror or stderror_r.
I have checked the specific header file declraing the function that uses sys_errlist and it doesn't have a diagnostic pragma.
I am using GCC 3.3.1 on a 64 bit RHE4 machine
Related
i am trying to compile this git https://github.com/yapb/yapb locally
i am using ubuntu 64bit, and it says i must compile 32bit
i am using now
CC=clang CXX=clang meson build-clang
but get this error
FAILED: yapb.so.p/src_chatlib.cpp.o
clang -Iyapb.so.p -I. -I.. -fvisibility=hidden -flto
-fcolor-diagnostics -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -Wnon-virtual-dtor -Wextra -Wpedantic -Werror -std=c++14
-fno-exceptions -O3 -DVERSION_GENERATED -fno-threadsafe-statics
-fno-exceptions -fno-rtti -m32 -pedantic -fdata-sections
-ffunction-sections -mtune=generic -fno-builtin -funroll-loops
-fomit-frame-pointer -fno-stack-protector -fvisibility=hidden
-fvisibility-inlines-hidden -msse2 -mfpmath=sse -fPIC
-isystem../ext/crlib -isystem../ext -isystem../inc -isystem..
-isystem. -MD -MQ yapb.so.p/src_chatlib.cpp.o -MF
yapb.so.p/src_chatlib.cpp.o.d -o yapb.so.p/src_chatlib.cpp.o -c
../src/chatlib.cpp
In file included from ../src/chatlib.cpp:8:
In file included from ../inc/yapb.h:10:
In file included from ../ext/hlsdk/extdll.h:28:
In file included from ../ext/crlib/crlib/string.h:17:
../ext/crlib/crlib/array.h:15:10: fatal error: 'initializer_list' file not found
#include <initializer_list>```
Double-check the pre-requisites mentioned in YaPB Building the Bot page.
Try and open a regular CMD (instead of Powershell), making sure it inherits all your previous setups (meaning its %PATH% does reference g++.exe, pip.exe, and so on.
$ make
clang++ -o build/blist.exe src/driver.cpp src/BList.h -O0 -g -Wall -Wno-unused-parameter -Wextra -Wconversion -Wold-style-cast -std=c++14 -pedantic -Wold-style-cast
clang: warning: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated [-Wdeprecated]
clang: error: cannot specify -o when generating multiple output files
My template implementation is in BList.cpp, but BList.h includes BList.cpp. That's why I pass the header in as an object. I don't know how to set clang to compile!
My header must be named "BList.h" according to my professor.
These parameters compiles with GCC, but not with Clang.
The error has nothing to do with including BList.cpp in BList.h (though that's a dubious practice by itself).
The problem is that you pass src/BList.h to Clang as if it was a source file. The build instruction should be:
clang++ -o build/blist.exe src/driver.cpp -O0 -g -Wall -Wno-unused-parameter -Wextra -Wconversion -Wold-style-cast -std=c++14 -pedantic -Wold-style-cast
You should update your makefile accordingly.
We are using two frameworks, Beast and Boost, when compiling one of our applications. In some Boost code used by Beast, a warning is generated by g++, because it thinks there is a possible uninitialized variable. However, we include boost and beast using the "-isystem" flag. This should stop the warning from being shown, but it isn't. Any ideas why?
Below you can see the compilation command and its output, with some anonymization.
/home/user/code/thirdparty/supplier/6.0/sysroots/x86_64-suppliersdk-linux/usr/bin/arm-supplier-linux-gnueabi/arm-supplier-linux-gnueabi-g++ --sysroot=/home/user/code/thirdparty/supplier/6.0/sysroots/armv7a-neon-supplier-linux-gnueabi -DBOOST_ASIO_DISABLE_EPOLL=1 -DEIGEN_MPL2_ONLY -DUSE_LOG -DLOG_THROUGH_SERVERSERVICE=1 -DARM -DNDEBUG -DAPP_TYPE_IS_PT -DOSIRIS_RELEASE_NUMBER=\"0.0\" -DLOGCONFIGFILE=\"app1_dev.log4\" -DCONFIGFILE=\"app1_native.cfg\" -DCONFIGFILE=\"app1_native.cfg\" -DLOGCONFIGFILE=\"app1_dev.log4\" -pthread -std=c++11 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O2 -ftree-vectorize -ffast-math -Wall -Wextra -Wno-unused-parameter -Wcast-align -Wuninitialized -Wmissing-include-dirs -Wpedantic -I binaryprotocol/include -I common/include -I config/include -I connectivity/include -I core/include -I socketserver/include -isystem /home/user/code/thirdparty/boost/1.64.0/arm/b993705d/include -isystem /home/user/code/thirdparty/log4cplus/1.2.0/arm/b993705d/include -isystem /home/user/code/thirdparty/openssl/1.0.2j/arm/b993705d/include -isystem ../external/common/modernjson -isystem ../external/common/pstreams -isystem ../external/common/beast/include -MD -MF ../osiris-obj/arm/b993705d/mains/app1/TLSWSClient.d -c mains/app1/TLSWSClient.cpp -o ../osiris-obj/arm/b993705d/mains/app1/TLSWSClient.o
In copy constructor ~boost::asio::detail::consuming_buffers<Buffer, Buffers>::consuming_buffers(const boost::asio::detail::consuming_buffers<Buffer, Buffers>&) [with Buffer = boost::asio::const_buffer; Buffers = beast::detail::buffer_cat_helper<beast::http::detail::chunk_encode_delim, boost::asio::null_buffers, boost::asio::const_buffers_1>]~:
cc1plus: warning: ~*((void*)& second +8)~ may be used uninitialized in this function [-Wmaybe-uninitialized]
In file included from /home/user/code/thirdparty/boost/1.64.0/arm/b993705d/include/boost/asio/impl/write.hpp:23:0,
from /home/user/code/thirdparty/boost/1.64.0/arm/b993705d/include/boost/asio/write.hpp:618,
from /home/user/code/thirdparty/boost/1.64.0/arm/b993705d/include/boost/asio/buffered_write_stream.hpp:29,
from /home/user/code/thirdparty/boost/1.64.0/arm/b993705d/include/boost/asio/buffered_stream.hpp:22,
from /home/user/code/thirdparty/boost/1.64.0/arm/b993705d/include/boost/asio.hpp:38,
from ../external/common/beast/include/beast/websocket/stream.hpp:18,
from ../external/common/beast/include/beast/websocket.hpp:14,
from mains/app1/TLSWSClient.h:13,
from mains/app1/TLSWSClient.cpp:11:
/home/user/code/thirdparty/boost/1.64.0/arm/b993705d/include/boost/asio/detail/consuming_buffers.hpp:191:38: note: ~*((void*)& second +8)~ was declared here
typename Buffers::const_iterator second = other.begin_remainder_;
Running Ubuntu 16.04. g++ provided by a supplier, its version below.
/home/user/code/thirdparty/supplier/6.0/sysroots/x86_64-suppliersdk-linux/usr/bin/arm-supplier-linux-gnueabi/arm-supplier-linux-gnueabi-g++ --version
arm-supplier-linux-gnueabi-g++ (GCC) 5.3.0
"-i" doesn't always prevent all warnings. There was a period of time where gcc produced false positives for "maybe uninitialized." This looks just like one of those times.
I am just curious if the position of the standard selection switch (-std=c++11 for my case) is relevant in g++ command line or not. The reason is that the following:
g++ -ftest-coverage -fprofile-arcs -std=c++11
-ansi -fpermissive -finline-functions -Wno-long-long
-fvisibility-inlines-hidden -m64 -Wall -Wextra
-g -o CMakeFiles/common.dir/cryptoclass.cpp.o
-c /home/work/common/cryptoclass.cpp
does not compile, while the following:
g++ -ftest-coverage -fprofile-arcs
-ansi -fpermissive -finline-functions -Wno-long-long
-fvisibility-inlines-hidden -m64 -Wall -Wextra
-g -o CMakeFiles/common.dir/cryptoclass.cpp.o
-std=c++11 -c /home/work/common/cryptoclass.cpp
does compile. The only change is that the -std=c++11 was moved to the end of the switches.
g++ gives the following warning:
error: #error This file requires compiler and
library support for the ISO C++ 2011 standard.
This support is currently experimental, and must
be enabled with the -std=c++11 or -std=gnu++11 compiler options.
Version:
g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
As per documentation, -ansi option enables the c++-98/c++-03 standard.
If you set multiple standard options, the latter option overrides the former. Same applies to other mutually exclusive options such as optimization levels.
I have a rather complex multithreaded code, which I compile using gcc 4.8.1. When compiling with
g++ -c file.cc -march=native -mfpmath=sse -mpreferred-stack-boundary=4
--param inline-unit-growth=50 -ggdb3 -Wall -Wextra -Winit-self
-O2 -fPIC -funroll-loops -fforce-addr -rdynamic
the code produced crashes with segfault (which I was unable to debug, but the address of a struct all of a sudden differs from what it was when constructed, in particular, is no longer aligned to 32bytes as required by the code but only to 8bytes).
When compiling with -O1 instead, the code works fine. I then added all the optimisation flags that make the difference between -O1 and -O2. (To this end, I created two files O1-opts and O2-opts via
g++ -march=native -mfpmath=sse -mpreferred-stack-boundary=4
--param inline-unit-growth=50 -ggdb3 -Wall -Wextra -Winit-self
-O1 -fPIC -funroll-loops -fforce-addr -rdynamic
-Q --help=optimizers > O1-opts
g++ -march=native -mfpmath=sse -mpreferred-stack-boundary=4
--param inline-unit-growth=50 -ggdb3 -Wall -Wextra -Winit-self
-O2 -fPIC -funroll-loops -fforce-addr -rdynamic
-Q --help=optimizers > O2-opts
when diff O1-opts O2-opts provides the option differences). When adding all the option differences to -O1, the code generated still does not crash. This puzzles me. So my question is: shouldn't this give exactly the same result as with -O2? (and also: what is the likely cause of my problem?)
The point is that the -O2 option not only sets different flags, but also enables additional optimizations in contrast to -O1.
The FAQ section of the GCC Wiki has an appropriate entry for this.