Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
We have investigated your problem and found a bug in VisualGDB. When running the gdbserver command VisualGDB always tries to use the deployment machine which is not set in your case.
We will fix this in the next release. As a workaround please enable the “Deploy executable on a different machine” checkbox in the VisualGDB Project Properties and specify the same machine as the deployment machine.If you get ‘broken pipe’ messages please ensure that no other valgrind instances are running in the background.
support
KeymasterHi,
Please try disabling the inline building. Click Tools->Options, select VisualGDB->General and set “Enable Inline Project Builder” to “False”.
support
KeymasterHi,
Are you talking about Linux or Windows projects? For Windows it’s not supported, on Linux you need to update to VisualGDB 3.1 to see the output.
support
KeymasterHi,
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:enAfter modifying the file please restart your Linux machine and try running the wizard again.
support
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
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
KeymasterHi,
Please post the entire build log here. It should contain additional information that will help identify your problem.
support
KeymasterHi,
That`s a known bug of VisualGDB 3.0. Please download the 3.1 Beta 1.
support
KeymasterHi,
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
KeymasterWe`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
KeymasterHi,
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
KeymasterThis can be it. Is it declared directly inside std::map<> or somewhere else? How exactly is _M_t declared?
support
KeymasterHi,
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.
-
AuthorPosts