Forum Replies Created
-
Posts
-
It looks like the converted private key has invalid format. Please try generating a keypair using OpenSSH tools (e.g. from cygwin package or directly on Linux) and use the file generated by it.
If that works, please compare the format of that key and the key you have tried before.Hi,
You are correct about private and public keys. VisualGDB mentions the public key as the term that describes the authentication process is “public key authentication”. We will consider making the wording less confusing here.
If you have already setup the public key authentication with PuTTY, you need to convert its key to the OpenSSH format and specify it in the “OpenSSH key from file” field.It would be easier, however, to select “Password” and enable “Setup public key authentication”. VisualGDB will authenticate for the first time using the password, generate and save the keys, add the public key to the key list on the server and use the private key for authentication from now on.
Hi,
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.
Hi,
Please try disabling the inline building. Click Tools->Options, select VisualGDB->General and set “Enable Inline Project Builder” to “False”.
Hi,
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.
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:enAfter modifying the file please restart your Linux machine and try running the wizard again.
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.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.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.
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?Hi,
Please post the entire build log here. It should contain additional information that will help identify your problem.
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.
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.
