Forum Replies Created
-
Posts
-
Hi,
Please try adding the flags directly to the targets and target templates, e.g.:
$(BINARYDIR)/%.o : %.cpp $(all_make_files) |$(BINARYDIR) $(CXX) $(CXXFLAGS) -c $< -o $@ -MD -MF $(@:.o=.dep) <add your flags here>
Looks like you are missing some libraries in your project properties. Search the sysroot\usr\lib directory for files containing the undefined symbols from the error message and add the found library names (without ‘lib’ prefix and extension) to the library list in VisualGDB Project Properties.
Regarding real-time IntelliSense, you can try enabling Tools->Options->C/C++(VisualGDB)->Advanced->Code Completion->Suggest names while typing. If this is not what you meant, please provide us with a better example of what you are trying to achieve.
Please contact our sales at sales@sysprogs.com for details about the number of machines.
The Visual Studio compiler and GCC are not 100% compatible when it comes to complex C++ templates. You may need to adjust your code so that both compilers can handle this (the problem is well-known, so googling for specific errors should easily get the fixing instructions).
You can specify -std=c++11 or -std=c++14 in CFLAGS on the Makefile Settings page of VisualGDB Project Properties.
Hi,
Please add the directory containing the missing header file to the “Include Directories” field on the Makefile Settings page of VisualGDB Project Properties. Adding the file to the Solution Explorer simply makes it easier to open, but does not affect search paths used by the #include<> directives.
Hi,
Please ensure that the jni folder is located directly inside the “C:\Users\nzmora\AndroidStudioProjects\CameraProcessor\app” folder.
If this does not help, please share a tree of all files (cmd /c tree /f > tree.txt) in the project directory.
This does not indicate an error. It just means that those tools are not present in your toolchain and VisualGDB will use the Windows equivalents. In fact, VisualGDB 5.0+ does not show the ‘X’ even if the tools are missing, as this sometimes causes confusion.
Hi,
VisualGDB uses a different syntax for displaying pointers as arrays. Please use the following expression:
*foo@length
Most likely the problem happens because Visual Studio confuses some of the files downloaded from the remote machine with its own project files and refuses to create the project.
Please share the following:
- The exact directory of your project and the project name
- The screenshot of the message
- The contents of the directory when Visual Studio shows the error message
This should help us understand which files could be interfering with Visual Studio project creation.
Hi,
Actually one of our customers has contributed a package already and we are currently reviewing it and will be publishing an official one within the next few months.
We can provide you with the current version on the “as is” basis if you want to try it. Please email our support to get a download link.
Looks like the first problem is caused by some broken symlinks on the Linux side. You can investigate this by running “ls -l” in the target directory and checking that all symlink targets exist.
The glibc problem can be caused by incompatibility between your toolchain and the system image. Please try the instructions described here: http://sysprogs.com/w/forums/topic/raspberrypi-undefined-reference-to-clock_gettimeglibc_2-17/
Hi,
VisualGDB Linux edition can only upload sources from one directory (with arbitrary subdirectories), so you can simply change the source directory to point to the parent one if that helps. If your source files are scattered around several directories, you would need additional file transfer actions that are available in the Custom edition and higher.
Note that if you have purchased a license recently, you can upgrade from Linux to Custom for just the price difference.
Hi,
We have looked into the new TI MSP430 toolchain. Although it is based on the newer tools, it currently contains one major bug: if you use the -ffunction-sections flag that helps removing unused code from your binary, the debug symbols become unusable.
We have repackaged the toolchain (without TI proprietary tools) and uploaded it together with a one-click installer here: http://gnutoolchains.com/msp430/
Remember to remove the -ffunction-sections flag from the debug configuration flags, as otherwise you won’t be able to debug your code.
Hi,
Thank you for your feedback. We indeed did not update the MinGW64 toolchain because there is not much demand for it among our users. For the popular areas (like embedded ARM, supporting new Linux-based platform, etc) we do actually publish updated toolchains.
Furthermore, VisualGDB is not limited to a specific set of toolchains! You can use any MinGW release you wish. Simply point VisualGDB to it and it will be able to integrate with it. That’s why instead of rebuilding something that already exists we focus on adding usability features, quick setup features and state-of-the-art IntelliSense.
If you say VisualGDB is absolutely not worth it, you could try setting up Eclipse with the same toolchains. However you would quickly find that many time-saving features provided by VisualGDB are missing there. Regarding your .Net suggestion, thank you for it, we will address it in the next release.
