I am trying to view the contents of C++ STL Containers. I read here that the recent versions of gcc and gdb support pretty printing by default but when I tried to display a map I got the following:
Then, I tried to set up pretty printing according to this answer but still it shows the same output. Can someone please help me out? Thanks.
I am using Ubuntu 16.04, g++ 5.4.1, GDB 7.11.1 and python 2.7.12 (installed from their official sources).
It was stated in the other thread you mentioned that some versions of GDB work with Python 3 only.
That can be ruled out as possible reasons since you don't receive any errors as far as your description says.
Over at sourceware.org it is suggested that
You can extend gdb using the Python programming language. This feature is available only if gdb was configured using --with-python.
Not sure if you did because the guides you used don't mention it directly.
Mark was correct. I built my own version of gdb 8.0 with --with-python option but still I was not able to see container contents. gdb was showing all complex structure. So I followed Mark's suggestion.
You need to create a soft link (auto-load) in your gdb install directory.
If your gdb install directory is $HOME/gdb_install then
cd $HOME/gdb_install/share/gdb
ln -s /usr/share/gdb/auto-load auto-load
/usr/share/gdb/auto-load already exists on my Ubuntu installation. It's the gdb version 7.11.1.
After that gdb is showing container contents. Thanks Mark.
The gdb native to Ubuntu 16.04 should be able to pretty print a std::map; the python code which handles that is class StdMapPrinter in the following file from the libstdc++6 package:
/usr/share/gcc-5/python/libstdcxx/v6/printers.py
If your goal is to accomplish this with binaries you build from source, it might still be useful to get this working with the native Ubuntu packages first, as a basis for comparison. The likely reason pretty printers are not working in a gdb you built yourself is that libstdcxx/v6/printers.py (libstdcxx.v6.printers in the python namespace) is not where gdb expects to find it.
Also, the gdb native to Ubuntu 16.04 is linked against python3, not python2; one way to see that is in the output of
ldd /usr/bin/gdb
It appears that the libstdcxx.v6.printers native to Ubuntu 16.04 is intended to work with either python2 or python3.
If your native gdb binary is not already installed, you can use this:
apt install gdb
Related
So I have been trying to install the graph-tool module on my Ubuntu system all day now. I just cant seem to figure it out. Basically I want to use the package in jupyter notebook (in an anaconda enviroment). I followed several installation instructions, but nothing seems to work.
This for example: https://gist.github.com/dlozeve/ed59bba8bc8cb9b21e2af36cc9766938
I get to the configuration (adjusting for the fact that I am using python2.7),
./configure --prefix=/home/timo/anaconda2/envs/graph/ --with-python-module-path=/usr/local/lib/python2.7/site-packages
yielding:
configure: error: *** A compiler with support for C++14 language features is required.
Does anyone know what I might be doing wrong? Or as a simpler way to get graph-tool to work in my jupyter notebook?
Thank you very much!
The configure script is telling you exactly what is wrong: You need a compiler with C++14 support. This just means that your GCC is too old.
(You haven't told us any pertinent detail, such as the compiler version you have, library versions, etc, so we can only guess. But luckily, the configure diagnostics is crystal clear.)
A simpler way to install graph-tool would be for you to upgrade your distro (14.04 is outdated) and use the Ubuntu packages, as described here: https://git.skewed.de/count0/graph-tool/wikis/installation-instructions#debian-ubuntu
As graph-tool does not seems to run in an anaconda environment and Ubuntu 14.04 does not have support the latest C++ compiler that is needed, I did install Ubuntu 16.04 and followed firstly [https://www.google.de/amp/s/www.rosehosting.com/blog/how-to-install-jupyter-on-an-ubuntu-16-04-vps/amp/] and then finally installed graph-tool as described on the homepage.
This way I get to use jupyter notebook and am still able to import graph-tool.
I've got an error ".gdbinit: No such file or directory." when trying to debugging in Omnet++ 4.2.2 in Ubuntu 12.4. It seems that the debugger cannot find ".gdbinit", or the find the one not compatible. So where can I find ".gdbinit" in my PC, or where should I find the right version of it to replace? Any idea would be appreciated!
Danh
Hi all, I have alternative solution for my problem and would like to write here for those who need to refer later. Instead of using gdb we can use valgrind. As my understanding, it is pretty good tool to detect bug related to memory allocation. To use valgrind in Omnet, you must make sure to have it installed in your OS (e.g., in Ubuntu, just type sudo apt-get install valgrind). Then in Omnet IDE, simply choose Profile As.. instead of Debug As.. then choose Omnet++Simulation, then trace bugs in valgrind windows. I did find where my bug is by this way.
Thanks.
Danh
the problem is already known, that gdb doesn't work with OS X Sierra anymore.
This is really annoying, since I researched already about the solution, and there were some solutions, but they apparently don't work anymore. I tried to use the .gdbinit file solution and the disable csrutil solution, both doesn't work.
Sooo my question is: Does anyone know how to fix it in 10.12.3 ?
Thank you very much!
Looks like there still isn't a solution to this. I don't think "use LLDB instead of GDB" is the ultimate solution. So I went ahead and built a fairly basic docker container which contains the very basics (g++ and gdb).
Here is the Docker Hub container, and the the Dockerfile is on this Github repo.
This solution at least allows you to use GDB on your Mac via a couple simple commands. And since the folder you're coding on is mounted, as soon as you hit save, all your changes appear automatically.
Hope this helps someone else out there.
So thanks to Basile Starynkevitch, who just gave me the idea to update gdb
SOLUTION:
You simply have to update gdb for the latest version (which is 7.12.1 currently). Assuming you have installed Homebrew:
That's what I did:
brew update
brew remove gdb
brew install gdb
It has now updated to the latest version.
Now codesign gdb again with the cert that you used before.
sudo killall taskgated
codesign -fs gdb-certi /usr/local/bin/gdb
launchctl load /System/Library/LaunchDaemons/com.apple.taskgated.plist
Last step is still to use the workaround to create the .gdbinit file:
nano ~/.gdbinit
-> set startup-with-shell off
Debugging works for me now :) (OS X Sierra 10.12.3 - gdb 7.12.1).
UPDATE:
Apparently it will fix certain problems, but not the whole problematic itself. It will still cause errors. Honestly, my solution: When you can: Switch to LLDB and another IDE (Netbeans does not support LLDB). Or use Linux. I currently use Ubuntu with a stick on my MacBook Pro.
None GDB 7.11 or 7.12.1 will not work on Sierra 10.12.4 In short it's because of Apple security upgrade. We need to wait for re-enabling when some new version will shows up.
Easy WA is to use LLDB as a debugger for now. Sample instructions here
Another LLDB instruction here
I found that gdb 7.12.1 did not work for me either. I do not think it includes the crucial commit 82b19a4d2f9c9e8d56f to gdb made on the 9th Nov 2016.
I was able to get the gdb 8.0 development branch to work, however.
Download with, e.g.
git clone --depth 1 --branch gdb-8.0-branch git://sourceware.org/git/binutils-gdb.git
Then go into the checked-out directory
cd binutils-gdb
I have macports so (a) wanted to link to macports libraries and (b) wanted to avoid putting stuff in /usr/local so configured with
./configure prefix=$HOME LDFLAGS="-L/opt/local/lib" CPPFLAGS="-I/opt/local/include"
make -j8
make install
=> puts gdb executable into ~/bin; (static) libraries into ~/lib; documentation into ~/share
Then follow André's tip above to do the code signing; though it will now be
codesign -fs gdb-certi ~/bin/gdb
I am using c++/eclipse kepler on mac, and I cannot debug any project. The error is "Error while launching command: gdb --version" Besides that, I can build and run my code using other libraries.
I searched a site that is similar to my problem: Debugger for C++ eclipse gives the following error. 'Launching program name' has encountered a ... Error while launching command: gdb --version
But what should I change if I am using a mac?
You can fix this by specifying the full path to gdb. You can do this separately for each debug configuration, and you can also set the default gdb location in the preferences under C/C++ > GDB. For example, if you installed gdb via Homebrew, then it's probably located under /usr/local/bin:
And here's a screenshot of the Preferences:
I still don't know why Eclipse can't find GDB even though it is on my path. I guess it doesn't use my .bash_profile or my .bashrc? You could try symlinking gdb into /usr/bin. Maybe Eclipse will look there.
Edit: I tried the symbolic link idea and now Eclipse can debug, but it crashes inexplicably while doing so! So, I guess... don't do that?
This guide from a UC Irvine Computer Science professor's page is a very well-written, detailed, and Mac-specfic description of all the steps involved in installing GDB, creating a certificate, signing GDB using that certificate, and finally configuring Eclipse. I was found this very helpful as someone unfamiliar with each of these steps.
GDB Installation on Mac OS X
I had the same problem. I solved it by:
Install a gdb - ( I used 7.8.1) - compile and install it. It got installed in usr/local/bin
Codesigning certificate
Open eclipse executable using sudo. Otherwise I still get the error.
I am on OS X.
Hope this helps.
I had this error too now, and spent more than an hour looking for it.
In my case, the path was correct, and eclipse seemed to fail to start "any" executable as debugger. (I tested with gksudo cat, but it clearly never got to effectively running it).
The final reason was that I had put in my eclipse.ini -Xms1G and -Xmx1G. It seemed to already use the full memory for the indexer, and trying to allocate some more memory to start the debugger failed with an "unkown" error. Removing the memory limitations fixed the issue.
Hope this helps someone
I had many difficulties making GDB to work on Eclipse. I tried LLDB instead and it worked like a charm:
https://wiki.eclipse.org/CDT/User/FAQ#How_do_I_get_the_LLDB_debugger.3F
This can be a more convenient alternative for Mac users.
Mac OS Sierra 10.13.6 gdb 8.0.1
had the same error as topic-starter.
first, I set the path as Neil Traft (here in the answers) explains to usr/local/bin/gdb;
But it didn't work.
I found these instructions:
https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d
and I discovered that I already had gdbcert1 in my System. So I followed everything from 7. Works!
I've gone to http://sourceforge.net/project/showfiles.php?group_id=2435, downloaded the Automated MinGW Installer for MinGW 5.1.4 and at the same time the GNU Source-Level Debugger Release Candidate: GDB 6.8-3. I've then installed MinGW base tools into C:\MinGW. No problem so far.
However when I come to install the gdb debugger it has a lot of files and folders with the same names as some already installed but the files are different to those already installed. e.g C:\MinGW\include\bfd.h is 171 KB but gdb-6.8-mingw-3\include\bfd.h is 184 KB.
How do I add gdb to MinGW without breaking what's already installed?
In a command prompt I browsed to C:\MinGW\bin and ran:
mingw-get.exe install gdb
That fixed it for me. Not sure if it matters but I have C:\MinGW\bin in my path (guess I probably didn't need to browse to C:\MinGW\bin).
The Current Release (5.2.1) version of gdb at the project files page has always worked for me. The download is a stand-alone .exe, you don't need anything else.
But I'll bet the .exe in the 6.8 package will work, too. I'd try using just the .exe, and then if there are problems, try extracting the other files from the 6.8 package. (Though that may cause problems with the rest of the MinGW installation.)
Update: There seems to be a 7.something version. I haven't tested it thoroughly, but it seems to work, even with gcc 3.
Get Wascana Desktop Developer. It combines MinGW, gcc, Eclipse and gdb in one package.
You can safely overwrite the files prepackaged with MinGW with the (newer) ones from the gdb tarball. You can also choose not to overwrite them - just make sure to pick either one set, i.e. avoid mixing files from the older and the newer package.
Most of the offending files are probably not really relevant to you anyway. For example, the files belonging to the libbfd library aren't required for gdb's day to day operation, they're used if you want to extend the debugger or write debugging tools yourself.
At any rate, make a backup of the mingw directory before untarring the new release. It's very easy since MinGW is self-contained in that directory. That way, if anything should malfunction, you can just delete the directory and restore from the backup.
Usually for installing gdb in windows, You have to 2 ways to install:
1) use ready-made binaries that were build and compiled from GNU gdb by some provider (easy to install)
use TDM-GCC binaries provided from the following URL and that is including inturn the gcc complier and also gdb debugger.
http://tdm-gcc.tdragon.net/
use Equation package inside which GNU GDB was already compiled and built.
http://www.equation.com/servlet/equation.cmd?fa=gdb
2) use minimal mingw or cygwin package then after install gdb inside it.
Install either mingw or cygwin inside which GDB is already shipped
Open cygwin or mingw terminal and just type the following to make sure it is already installed
$ gdb --version
Hint: if you did not find gdb installed, simply open the cygwin or mingw package installer and make sure you already check gdb
Hint: getting and installing a debug build of the OHRRPGCE is providing useful information about crashes.
From cygwin or mingw terminal, Start gdb using the following
c:\mingw\bin\gdb.exe program_to_debug.exe
REF: http://rpg.hamsterrepublic.com/ohrrpgce/GDB_on_Windows
The TDM GCC/MinGW32 builds installer includes gdb. It's gcc 4.4.x with all the core binary packages required for basic Windows development, and is widely used without any unusual problems.