I am using GDB 7.8.0.20140729-cvs and GCC 4.8.2. Whenever I try to print the value of a variable referenced by an rvalue reference, I get an error from the debugger complaining about an unknown type, forcing me to manually cast the T && to a T *.
Are there newer versions of these where this bug is fixed? Ideally I'd prefer not to upgrade GCC if I don't have to?
Are there newer versions of these where this bug is fixed?
No.
Upgrading GCC won't help because it is already doing the right thing (emitting DWARF DW_TAG_rvalue_reference_type entries).
But GDB's handling of rvalue references is still broken even in the latest Git sources.
The relevant bug is https://sourceware.org/bugzilla/show_bug.cgi?id=14441
Related
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.
After hours of research (and tries) on how to install id3lib on Qt (windows), but with no success, I decided to use TagLib's library.
I followed this tutorial to build a compatible version of taglib for Qt but still another problem (full log here):
...
C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: Dwarf
Error: found dwarf version '4', this reader only handles version 2 and 3
information.
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib/crt2.o:crt1.c:(.text+0x1f1):
undefined reference to `__chkstk_ms'
...
In CMake, I did configure > MinGW Makefiles.
Can anyone tell how to fix it?
Environment:
Windows 7 (64-bit);
CMake 2.8.12.1;
TagLib 1.9.1;
GCC 3.4.5;
Qt 5.1.1.
The problem stems from the fact that you are using terribly outdated GCC, while your Qt binaries are most likely built with bleeding-edge GCC (or the one close to it). For instance, as the error message shows, DWARF is outdated in case of your current GCC and is incompatible with the one used by your current Qt. Furthermore, even if it wouldn't, you'd still hit other problems with binary incompatibilities, since you essentially mix compilers with different major version numbers, which is strongly discouraged. Notice, that your problem has nothing to do with CMake at all. You can see it yourself in the error message, i.e. the error is reported by ld, the linker utility from (your outdated) GCC toolchain. To conclude, your only option is to update GCC, ideally exactly to the one which was used to build your current Qt.
How can I know the libstdc++ shipped with each gcc version? Is there an an easy way to get this info without the need to install the gcc?
You look in the manual, specifically at http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html which shows the library version numbers for each GCC release.
You can just check the GCC source code, for example the libstdc++/ChangeLog file that comes with it. It shouldn't be too hard to script that.
At first sight, libstdc++ isn't getting real version numbers anymore, they just use the source code repository revision id in the ChangeLog files.
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.
I have build a g++ v4.4 from source by using the archives provided by gcc.gnu.org.
But the resulting g++ cannot compile some of our projects c++ files. I am receiving a message simply saying: assembler error. It turned out that the assembler chokes on some extremely long symbol names, e.g. symbols names with a length of more then 2k.
Am I missing something to get it to work?
I would very appreciate an advice on how to get this working!
Environment: Debian-Lenny 64bit
EDIT: The mentioned c++ files are compiling fine with g++ versions v4.2 and v4.3. So I don't think it is a bug in the assembler (from binutils v2.18). Just to be sure I have also tried with binutils v2.20 - but I got the identical error message.
EDIT: I need g++ v4.4.x for the purpose of comparing the output of different g++ versions (and there is no g++ v4.4 in the official lenny repositories)
If your analysis is correct, it seems the proper course of action would be to file a bug for binutils. Or gcc, if it turns out the long symbol names are due to a bug in gcc's name mangling.
Of course, a (preferably reduced) testcase will help the developers fix your problem. Heck, it could have helped SO readers to verify your problems.
You're going to have to compile the corresponding gas instead of depending on what lenny has in his refrigerator (/usr/bin).
Why don't a) upgrade or b) use the backports archive or c) rebuild from current Debian sources on your box? I happily run testing with g++ 4.2, 4.3 and 4.4.
Worst case, you could install a new Debian release in a virtual environment such as a chroot, a Xen or Kvm instance, or inside VirtualBox.