[ket]

Hi,

For Linux and Windows projects go to View->Toolbars->VisualGDB. You can enter the arguments in the Executable Arguments field on our toolbar. You can also enter the arguments on the Debug settings page in VisualGDB Project Properties in the Main executable arguments field.

[ket]

Hi,

Likely IntelliSense does not recognize the types as the relevant header directories have not been specified. Please try adding the gnustl header directory to IntelliSense directories in VisualGDB Project Properties. The directory you need to add should be “sourcescxx-stlgnu-libstdc++4.8include” under your Android NDK installation directory if you are using the 4.8 gcc toolchain.

[ket]

Hi,

VisualGDB is a .Net 2.0 executable (to make it compatible with Visual Studio 2005). When it is loaded into Visual Studio 2013, it is loaded as a .Net 2.0 assembly into a .Net 4.5 process. However when you run the executable, Windows detects that .Net 2.0 is missing and shows a prompt to install it (v3.5 includes v2.0). Please proceed with installing it, this won’t downgrade any existing frameworks but will simply provide support for .Net 2.0 applications.

[ket]

Hi,

Thanks for reporting back, good to know it works now. Yes, you should avoid using paths with spaces in them when using gnu tools. Even if make would accept a path with spaces in it, then gdb could still produce strange errors etc.

[ket]

Hi,

VisualGDB build variables are usually derived from the project settings or our generated Makefile.

For Linux projects the Target-related build variables are derived from the BuildDir variable and TARGETNAME and BINARYDIR from the makefiles. If you change these variables in the makefiles then the library/executable will be built into a different directory under a different name.

[ket]

Hi,

The Android NDK build system usually expects all the source files to be in the jni subdirectory of the project. VisualGDB updates the LOCAL_SRC_FILES list automatically on each build based on the files that are part of the project in VS. You can disable this behavior by removing the comment line above the variable.

The simplest way to use your existing source in the new app would be to copy the sources to the jni directory and then adding them as existing items to the project in Visual Studio.

You can also try to use the existing sources from their current location (disable the VisualGDB source files updating then). The source files should be added with their relative paths to LOCAL_SRC_FILES and the relative include directories to LOCAL_C_INCLUDES in Android.mk. Please read the ANDROID-MK.html documentation from the docs subdirectory of your Android NDK install directory for further information on these variables.

[ket]

Hi,

Do you mean that you have fixed the issue? The LOCAL_C_INCLUDES can be specified identically in Android.mk and in our Makefile settings gui as the graphical interface is directly tied to the Android.mk file.

[ket]

Hi,

Are all relevant files transferred to the remote machine at least once i.e. have you added .cc to the source file transfer filter on the Project settings page in VisualGDB Project Properties? Is the local source directory set correctly for file transfer?
Have you tried setting the option to transfer all the files all the time? Does this option work?

It is normal that source transfer does not detect remote changes as the change checking is done locally only, comparing the remote source files with the local files each time would take too much time in the case of many files.

[ket]

Hi,

The underlying build system for Android is make, so you can just pass the -j argument to ndk-build.

You can specify ndk-build arguments on the Build settings page of VisualGDB Project Properties. You can read more about the make jobs argument here.

[ket]

Hi,

Please look in the Output window for the complete error message.

This is a generic error meaning that the build failed and the error could not be mapped to project source files, usually it means the error is a missing reference or tool error.

[ket]

Hi,

Yes, that is exactly what choosing the STL value in VisualGDB Project Properties does as well.

[ket]

Hi,

For large project trees, we would advise using shared directories.
When using shared directories, make only the root directory containing all the project directories shared. Then use the directories within it as source directories for projects.

If these directories are going to be made into separate VisualGDB projects in one solution anyway, then you will not need to setup the entire root directory for one project. You should just setup the dependencies between the projects and have each project handle its sources separately.

[ket]

Hi,

Based on the log you attached, the breakpoints are hit successfully. The log indicates no problems setting the breakpoints correctly. We would need to see the log where the breakpoints are not hit to be able to tell what the issue is. However, based on the log and the description of your workaround the breakpoints are even then probably set correctly.

Are you trying to set breakpoints in code that is called very early in the app startup? If so, please try setting the Android->Debug Options->Debug App Startup option.

[ket]

Hi,

You must tell the Android project to use the STL library.

Please go to VisualGDB Project Properties and on the Makefile settings page choose the STL library version you wish to use (e.g. stlport_shared).
You can read more about the different STL library versions from docsCPLUSPLUS-SUPPORT.html under your Android NDK install directory.

[ket]

Hi,

Currently SmarTTY does not accept any command-line arguments.
Please let us know which use cases you think would require them and we will consider adding support for it.

[Author]

Posts