[support]

Hi,

VisualGDB sets the GCC language to English by setting the LANG environment variable to en_US.UTF8. Looks like some settings on your computer override this and cause the messages to appear in German.
Please try adding the following lines to your ~/.profile file:
export LANG=en_US.UTF8
export LANGUAGE=en_US:en

After modifying the file please restart your Linux machine and try running the wizard again.

[support]

Hi,

It looks like you have changed the locale for one SSH window only. When VisualGDB opens anther SSH channel, the locale is still German. Please modify the global setting instead.
Please refer to the documentation of your Linux distro for details on changing the default locale for a user.

[support]

Hi,

This can be due to the default language of your Linux user account. Please try changing the language of the Linux account you are using with VisualGDB to English so that VisualGDB can understand the messages produced by GCC.
Regarding the support language, we only offer it in English.

[support]

Hi,

The INCLUDE_DIRS syntax in the makefile you provided looks incorrect. Please use the unix-style relative paths. E.g. if your makefile is in the directory c:projectsproject1 and the include directories are c:projectsproject1rac and c:projectscommon, please specify “rac ../common”. Please ensure that there are no spaces in the project directory. Alternatively you can add absolute paths in MinGW format (e.g. c:/projects/project1/rac).

Regarding the static library names, please first add the library directories to the LIBRARY_DIRS using the same syntax as INCLUDE_DIRS. Then add short library names to LIBRARY_NAMES (e.g. if your library is called libTest1.a, just add Test1 to LIBRARY_NAMES).

If nothing helps, please rebuild your project and post your build log and the build directory name here. The build log should include the G++ command line that specifies the include directories.

[support]

Hi,

Did you let VisualGDB generate a makefile/flags.mak, or did you reuse an existing makefile?
Does the makefile in your project directory have any comments related to VisualGDB?

[support]

Hi,

Please post the entire build log here. It should contain additional information that will help identify your problem.

[support]

Hi,

That`s a known bug of VisualGDB 3.0. Please download the 3.1 Beta 1.

[support]

Hi,

If you could quote a good example showing how using those functions simplifies viewing of complex data types, we would certainly consider supporting it in the future versions.

[support]

We`re sorry to hear that most of the tool version combinations did not work, however we cannot do much about it, as the GNU tools are out of our control.
We could only recommend using Ubuntu or other more popular Linux distributions that have bigger communities and fewer bugs.

[support]

Hi,

That is starting to look like a GCC or GDB bug. Can you try using a newer version? Will GDB accept map<...>::_RepType in another context? Will it handle map::key_type?

[support]

This can be it. Is it declared directly inside std::map<> or somewhere else? How exactly is _M_t declared?

[support]

Hi,

That is correct. However, we need to find a type that can be represented from the type of your map. E.g. std::map<...>::some_name. I.e. there should be a definition ‘typedef std::_Rb_tree<...> some_name;’ somewhere inside the std::map implementation. The name used in this typedef is what we are looking for.

Please try to find the declaration of _M_t. The code is pretty obscure, so you might need to use search instead of ‘go to definition’. Let us know the type used in the declaration.

[support]

Hi,

Please find where exactly _Rep_Type is declared on your machine (i.e. within which class). Alternatively you can add _M_t to the watch window (use correct stack frame) and see the type column for more hints.

[support]

Hi. Sorry for the delayed reply. We were trying to reproduce the problem on our Linux setups, but were unsuccessful.
Your problem is caused by VisualGDB trying to get cast the tree node pointer to a class that contains information about the descendents and the value. Normally this class is available as std::map<...>::_Rep_type::_Link_type.
It looks like your version of STL has different names for it. Please try the following steps to get the name of the tree node class:

1. Create a trivial program:

std::map test;

test[3] = 3.5;

2. Step into the second line by pressing F11.
3. Keep stepping into the STL code until you reach the _M_end() method:

_Link_type
_M_end()
{ return static_cast<_link_type>(&this->_M_impl._M_header); }

4. Please take a note of the return type of _M_end(). In our case it’s _Link_type.
5. Use the ‘call stack’ window to find the innermost frame that belongs to the map class itself. In our case this is map<...>::lower_bound():

iterator
lower_bound(const key_type& __x)
{ return _M_t.lower_bound(__x); }

6. Find where _M_t is declared and take a note of its type. In our case it’s _Rep_type:

_Rep_type _M_t;

7. In the GDB Console select ‘All GDB interaction’ and find the line causing the error you mentioned. Copy it and rerun the command to ensure that GDB still complains.
8. Modify the line to use the node type name you have derived. Ensure that GDB executes the command successfully.
9. Send us the node type name you have found. We will update our type visualizers to support your version of STL.

[support]

The easiest way would be to let VisualGDB connect via SSH already as root:

1. Open a root shell with ‘sudo su’
2. Change the root password with ‘passwd’
3. In VisualGDB Project Properties (right-click on the project file to open) find the ‘Remote Computer’ setting, select ‘New connection’ and enter ‘root’ as the user name and the password you set in the previous step.

From now on the project will be built and debugged as root.

[Author]

Posts