I just updated my msys gcc compiler from 9.2.0 to 10.1.0. Afterwards all functions inside std:: namespace cannot be found and are now behind namespace ::std:: with leading double colon and all Gtest MACROS e.g TEST are highlighted as errors. here's an example:
std::in_place without leading double colon gives an error : no member named "in_place" in namespace 'std::ranges::std'
It's known issue with CLion 2020.1.x. The current W/A is to use C++17 until they will fix it and provide bugfix update.
Related
I want my Windows C program compiled with GCC on MinGW64 toolchain to output inf, -inf etc. ANSI values instead of Windows specific one like 1.#IND.
So far I was adding the following line before including stdio.h to my header files to achieve it:
#define __USE_MINGW_ANSI_STDIO 1
That worked great and didn't cause any problems when using MSYS2 based distribution. That changed when I installed mingw64 build from winlibs (I need an older version of GCC than MSYS2 currently provides as GCC 12 introduced very significant performance regressions). The line gave me warnings about redefining macros. I've then found a post from one of the designers of MinGW system about it. Apparently that's an internal macro and shouldn't be used by the user. The suggested way is to define _MINGW_FEATURES so I tried:
__MINGW_FEATURES__ _MINGW_ANSI_STDIO
instead. While that worked for ANSI output it unfortunately resulted in the compiler not recognizing SCNu8 (or C99 standard %hhu) modifiers anymore.
What's the correct way to use GCC based on MinGW toolchain to both use ANSI STDIO output and allow C99 printf/scanf modifiers (like %hhu or at least SCNu8).
I am using an inline global variable which works well for the purpose of it.
class MyClass {
public:
void Func() {
}
}
inline MyClass myClass; // global inline variable
Above works well for my purpose but I get a warning when my code compiles on gcc with compiler below C++17. Following is the warning
warning: inline variables are only available with -std=c++1z or
-std=gnu++1z
Question:
How can I suppress the warning on gcc?
I tried to suppress the warning by using a #pragma like below
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wc++17-extensions"
inline MyClass myClass;
#pragma GCC diagnostic pop
Above #pragma technique works on clang, but looks like GCC to not understand the #pragma? I just want to brute force suppress the warning on GCC. How can I do that?
Looks like gcc warning options list does not even mention about this?
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
I am using gcc (GCC) 7.3.0
To understand why you cannot suppress this warning, look at what happens if the code is compiled with a compiler that does not support inline variables. (Inline variable support started with gcc 7.) Older versions of gcc process your code and spit out error: 'myClass' declared as an 'inline' variable. Not a warning, but an unsuppressible error. Hard stop; object code not produced.
Newer versions of gcc are able to be more understanding and helpful, but at the same time they have an obligation to maintain some degree of compatibility with older compilers. These newer compilers can recognize this C++17 feature, and it's been determined that ignoring "inline" downgrades the error to a warning (compilation does not necessarily need to stop). Furthermore, the message was given information about how to resolve this situation (assuming the code is correct). At the same time, this warning is still essentially the error produced by older versions of gcc, just given a makeover to make it more user-friendly. It cannot be suppressed any more than the old error could. Your choices are to write valid pre-17 code or to enable C++17 features.
I just started using MinGW for Windows. When trying to create executable using
g++ a.cpp -o a.exe -std=c++14
for the code below:
#include <string>
using namespace std;
int main()
{
string x = to_string(123);
return 0;
}
I'm getting following error:
C:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../libmingwex.a(vsnprintf.o):(.text+0x0): multiple definition of vsnprintf
C:\Users\..\Local\Temp\cc4sJDvK.o:c:/mingw/include/stdio.h:426: first defined here
collect2.exe: error: ld returned 1 exit status
What is the root cause for this error and how can I make it go away? While I can easily find a replacement for to_string() function I'm not sure what is causing this error to occur in the first place.
Installing MinGW packages mingw32-libmingwex-* will link an appropriate version of vsnprintf and avoid the linker error.
This issue, i.e. multiple definition of vsnprintf, still exists in MinGW as December 2019.
After investigating a lot, I found the solution in the official mailing list.
It's a bug in mingwrt-5.2.2. Downgrading to the mingwrt-5.2.1 version solves that issue.
To do that, just input the following command:
mingw-get upgrade mingwrt=5.2.1
Then restart the MinGW shell.
Read the full story here.
Note: MinGW-w64 and MinGW are separate projects, so the accepted solution is not so helpful to me, as I want to keep MinGW and not to move to MinGW-w64.
I solved this issue using MinGW w64 compiler
download mingw-w64-install.exe
setup to Version: 6.3.0, Architecture: i686, Threads: posix, Exception: dwarf and Build revision: 2.
I hope this will be of some help.
There are multiple definitions of vsnprintf in both stdio.h and libmingwex.a. I am able to work this around by adding #define __USE_MINGW_ANSI_STDIO 0 to the start of the code, before any includes, which disables the definition of vsnprintf in stdio.h.
I just restarted working on a project which has been on hold for a few months. Last time I compiled it it was working just fine, without any error nor warning.
Yet when I tried to compile it earlier today I got this warning
attention : ‘template<class _Operation> class std::binder2nd’ is deprecated [-Wdeprecated-declarations]
This warning literally appears hundreds of time when including Eigen/Geometry, which I use all over my project
In file included from [...]/include/Eigen/src/Core/ArrayBase.h:109:0,
from [...]/include/Eigen/Core:350,
from [...]/include/Eigen/Geometry:4,
from [...]/include/[myproject]/types.hh:8,
from [...]/include/[myproject]/voronoi.hh:8
Since then I haven't updated Eigen (is used 3.2.4 which is still the last update today).
However, since last time I compiled it, GCC has been updated to 5.1.0 (I'm using archlinux)
Question:
Is there an issue with gcc 5.1.0 telling me std::binder2nd is deprecated
Should Eigen be updated ?
How can I silent those specific warning without loosing the verbosity of my build ?
ANSWER
I appreas that std::bind2nd is really deprecated and that a commit has been done to solve that in Eigen. This commit is however not yet merged with the master branch :/ (and doesn't solve the issue as some std::bind2nd are still present in Eigen's code)
Bottom line is: Eigen's last stable version is deprecated
Is there an issue with gcc 5.1.0 telling me std::binder2nd is deprecated
No, the C++ standard says it's deprecated in C++11, so if you compile in C++11 mode then it is supposed to be deprecated.
Should Eigen be updated ?
Yes. if it wants to be C++17 compatible, as std::bind2nd doesn't exist post-C++14 at all.
How can I silent those specific warning without loosing the verbosity of my build ?
Suppress the warning. Either compile with -Wno-deprecated-declarations on the command-line or do it in the source when including the Eigen headers:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#include <eigen/whatever.h>
#pragma GCC diagnostic pop
Or, as the other answer says, tell GCC to treat the Eigen headers as system headers, which happens automatically if they are in /usr/include, or are included with -isystem, or are included from another header that does:
#pragma GCC system_header
#include <eigen/whatever.h>
How can I silent those specific warning without loosing the verbosity ?
Edit the CMakeLists.txt file. Add this line somewhere after CMAKE_CXX_FLAGS is set.
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-deprecated-declarations")
Previous answer mentioned adding this to #pragma or to command line. I am biased against #pragma because I find it hard later on to remember where I put it. So as general practice, I try to avoid #pragma. Adding to command line means you have to remember to type this everytime you recompile.
Instead of using the -I flag to include files use -isystem to include Eigen headers:
g++-5 -isystem/usr/include/eigen3 source_file_here.cpp
This flag is intended for system headers that don't conform to C standards but are considered false positives when warnings are generated. Eigen headers are used much like system headers and thus for most users the warnings are not helpful but merely an annoying false positive.
Credit goes to Ilya Popov's comment in the original question.
I've just compiled GCC 4.7 to work with stdatomic.h, but I can't seem to -I it. stdatomic.h seems to live in /usr/include/c++/4.4.3, but then the linker tells me it needs a bunch of other files in dirs nearby. If I -I all of them, I still get the error undefined reference to atomic_flag_clear_explicit. Any ideas how I'm supposed to link this right?
First, if you are compiling with GCC 4.7 you should not be including or linking anything from a directory from GCC 4.4.
Second, -I only affects the search path for header files. "undefined reference" is a linker error and usually means it hasn't found the right library. You change the library search path with -L. The linker didn't say it didn't find a library with the right name, it says it didn't find a symbol, so clearly the library it did find didn't have that symbol. I'd suggest you have a versioning problem, perhaps caused by a installation problem.
The <stdatomic.h> header in GCC 4.4 and 4.5 was from an early draft of C++0x atomics, but is not part of the final standard, so it was removed from libstdc++.
The C++ compiler supports C++11 atomics via the C++11 <atomic> header, so you should use that header in C++ code.
When the C compiler supports C11 atomics, the <stdatomic.h> header will be provided again.
Using this command solved the problem for me:
$ scl enable devtoolset-7 bash
I got the same error as you when entering sudo make altinstall for installing Python 3.8.5 on CentOS 7.