Why do I get error messages like "Unable to activate XX analyzer" in vscode? - visual-studio-code

I have added some extensions in vscode and after that, every time I open/switch to a tab with a C file, I am getting a dropdown with three error messages about not being able to activate analyzers. Why?
Here are the extensions:
and here are the error messages:

That should be caused by c/c++ Advanced lint module, well the same error can be caused by others modules, those errors occur, when you don't have those modules that you are getting warning about installed, in this case Clang, CppCheck, and flexeLint. Well for the two first you can download and install them from here:
clang: http://clang.llvm.org/ (go to download section)
cppCheck: http://cppcheck.sourceforge.net/
flexlint: here the bad news, that's not a free product, and some kind of expensive. http://www.gimpel.com/html/flex.htm
for those programs, once installed, by default should be added to the system path environment variable (if not you can do it yourself, cppcheck don't add automatically to path in windows), the thing if they are added to the path, vscode or the calling plugin here "c/c++ Advanced lint", will recognize them, because will test if the command is recognized at the console level. If you don't want to add those tools to path, you can still specify in parameters the path to those tools executables, for that you can follow the instruction for every module here they are :
cppCheck : https://marketplace.visualstudio.com/items?itemName=matthewferreira.cppcheck (using this setting cppcheck.cppcheckPath:)
clang: (clang.executable) see here: https://marketplace.visualstudio.com/items?itemName=mitaki28.vscode-clang
flexlint: (c-cpp-flylint.flexelint.executable)
and of course setting the path to executable in each one of those settings.
well you can also check that : https://marketplace.visualstudio.com/items?itemName=jbenden.c-cpp-flylint
it's so often that plugins depends on others programs, on which you need to install manually, and every time, you need to read the documentation for the module to be installed, to see what configuration you need to do.
for the warning about flexlint you can disable it by adding this to the user settings :
"c-cpp-flylint.flexelint.enable": false
that disable completely the use of flexlint, and so the plugin will not search for it. I'm not sure, may be setting cppcheck is sufficient, otherwise you have that to set. I personally have that set. Of course unless you count to buy the product and then just set the path.
hope you all, all the best!

Related

"Undefined variable: Environment" when editing SConscript file in Eclipse Neon

I have an SCons project (an implementation of the Generic Mapping Tools tutorial at http://gmt.soest.hawaii.edu/doc/latest/GMT_Tutorial.html using SCons rather than shell scripts), and I am using Eclipse Neon to edit the Sconstruct file.
The Sconstruct file starts in quite a standard way (the rest of the file is immaterial to this question).
import os
import collections
env = Environment(ENV = os.environ)
bld = Builder(action = 'ps2pdf $SOURCE $TARGET', \
suffix = '.pdf', \
src_suffix = '.ps')
What is annoying me is that while the build works perfectly using scons, Eclipse keeps marking the Environment and Builder constructions as "Undefined variables".
I installed the SConsolidator plugin, but it makes no difference.
I find the marking of an error that is not an error incredibly annoying.
While I could do something like tell Eclipse to ignore the error, I would prefer something more intelligent, such as adding Scons to the library path. I have tried adding C:\Python27\Lib\site-packages\scons-2.5.1\Scons and C:\Python27\Lib\site-packages\scons-2.5.1\Scons\Scripts to the Python Interpreter Paths (Window → Preferences → PyDev → Interpreters → Python Interpreters → Paths), and using an import directive like from SConscript.SCons import * but it doesn't make a difference.
Try library path:
C:\Python27\Lib\site-packages\scons-2.5.1\
Then
from SCons.Script import *
First thing first - if you know exactly where does your plugin keep it's symbol index(es) make sure that they don't get deleted by whatever the editor/IDE/build think they are doing to "be helpful".
Python plugins for editors easily get confused and you may need you to draw very explicit and detailed picture and train them a bit (by stopping the code in debugger) in order for a scanner/indexer to "wake up" and finally scan and index all symbols.
What I do in VS (with PTVS) is to make one proj for Scons_lib (home at C:\Python27\Lib\site-packages\scons-2.5.0), another for Scons_Scripts (C:\Python27\Scripts\, startup file: scons.py)
and then separate projects for separate scons driven folders/builds. To get editor to immediately recognize building files as Python I add extension .scons (google's convention used in Chrome build, Sconcsript's are ProjName.scons), tell VS that .scons is also Python, rename Sconstruct to Make.scons.
Then I run in debugger, (with -f Make.scons -n of course) as many times as I can :-) trying to place breakpoints in different files form different sub-packages that I know will run. Letting scons throw exceptions for nothing (like missing Sconstuct file) is also file - the goal is to force indexer to go places because it sees that debugger is going there.
After N runs, (and/or K days). PTVS (you can consider it a plugin) all of the sudden starts recognizing all symbols, packages, sub-packages, only can't penetrate things explicitly hidden behind caches.
Gave up trying to determine which events exactly make the scanner/indexer see the light. Probably something like seeing the number of files at "unexpected" paths being in debugger. Most symbols are visible in debugger immediately, except for the files that load first (scons.py and my own file that I exec from scons.py to inject whatever I want before anything else runs.)
Also I keep PYTHONDONTWRITEBYTECODE=1 to make sure that it always has to load actual .py-s
It might potentially help to have a single file that would exercise something form every sub-package, litter it with breakpoints and let it be run a few times.

Code::Blocks not working with GTK3 even after editing the script-gtk-win32-3.0.lib not present

Where do I get gtk-win32-3.0.lib from?
I am trying to use GTK3 with Code::Blocks. The thing is initially when I was trying to create a GTK project, it gave me an error that it can't find gtk.h. I then edited the wizard script and changed gtk-2.0 to gtk-3.0 as seen in an answer on Stack Overflow.
After doing that, it gave me an error cannot find gtk-win32-2.0. I changed this to gtk-win32-3.0 in the script but the error still persists.
I have both the files gtk.h and gtk-win32-3.0 in the GTK directory. I crosschecked this many times. Can someone help me with this?
I just discovered that I don't have a file 'gtk-win32-3.0.lib` in the gtk\lib directory. I manually created one in the directory and now Code::Blocks lets me create a project. I still don't know what should be present inside the library file.
Edit:
The project gets created after I added a blank file named gtk-win32-3.0.lib in the expected directory but the files doesn't get compiled.
Current error:error: ld returned 1 exit status
Didn't get more details regarding the error.
The same program gets compiled when used outside the project as an individual source file.
I just noticed I still have code::blocks installed (version 13.12). Note that I am on Linux. I just clicked on File|New|Project.
I then selected the new project to be a Gtk project, and most everything was ready.
You'll have to fill in a project name (Test99 in the screenshot) and a location.
I suspect you do need to have the gcc compiler installed, and of course the Gtk libraries. You'll also need pkg-config, which is necessary for configuration.
By default, the new project was configured to be a gtk-2 project. But you can change that by changing the part of the includes. Right click on the project name in the left panel (Test99), and select Properties. In Properties, select Project Build Options (don't be tempted to select Options instead of Properties in the previous step. I don't know why, but they're different!)
Select Linker Options, and you should see pkg-config gtk+-2.0 --libs with 'back-ticks' around it. Changing 2.0 into 3.0 should link with the libraries.
Go to Compiler Settings, then Other Options and again, you will find a similar entry pkg-config gtk+-2.0 --cflags (also with backticks). This detects where the gtk.h file lives. (Also change 2.0 to 3.0)
That should be it. This may not be the latest version of code::blocks. If you encounter problems, yell!

"Errors exist in the active configuration..." Eclipse Dialog when Debugging

An "Errors exist in the active configuration of project X. Proceed with launch?" dialog appears while debugging code in Eclipse. Hitting the "Proceed" button results in successful debugging. There are no apparent errors with the launch configuration. A similar Run Configuration does not generate the error.
This is caused by an invalid path somewhere in your Eclipse project settings. There are a couple common sources for this kind of error.
You're working on a shared (version controlled, copied, etc) project where someone has hardcoded a path that doesn't exist on your machine, or uses an environment variable that you've not set.
Sometimes, you can find the offending path by looking at the full list of Error messages. If not, look in your project file.
The Discovery Options in your project properties has 'Automate discovery of paths and symbols' enabled - but the process is generating an error.
If you're using a version of Eclipse that warns you this option is deprecated, uncheck the option to disable it and fix any includes in 'Preprocessor Include Paths' instead. If not. . .try it anyway.
Depending on your path changes, restart Eclipse and try again.
It starts the executable that was built last before you broke the build. That executable will be older then your source files. The reason you were able to debug is because your line numbers did not change for the code you've debugged - e.g. you may try break in main then introduce a compilation error and move main a couple lines below - the debug will highlight the wrong lines when it stops.

cannot load runtime-gdb.py

I'm trying to debug a program written using Go inside eclipse. I can set and hit breakpoints pretty consistently, but I cannot view the contents of my variables. When I start debugging the program, I always get the following error on my console.
warning: File "/usr/local/go/src/pkg/runtime/runtime-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/local/go/src/pkg/runtime/runtime-gdb.py
line to your configuration file "/home/johnlawrie/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/johnlawrie/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
Thinking that the problem might be due to the error message, I put the entry into my .gdbinit file as instructed. However, I get the same message every time I run as if I did nothing at all. This is the contents of my /home/johnlawrie/.gdbinit file
add-auto-load-safe-path /usr/local/go/src/pkg/runtime/runtime-gdb.py
Any ideas what I need to do to make this change take effect? I have tried logged off and back in.
Thanks,
John Lawrie
It did learn what was happening. When gdb is started from Eclipse/CDT, it is started with option -nx, which means it doesn't load .gdbinit in the home directory.
I was able to get this to work by creating a .gdbinit file as a peer to the src, bin, and pkg directories in my workspace and adding the following line to it
set auto-load safe-path /usr/local/go/
It should be add-auto-load-safe-path /usr/local/go/src/pkg/, not the path to the script.
Also keep in mind that gdb doesn't really work with Go, specially v1.3.
From http://golang.org/doc/gdb:
GDB does not understand Go programs well. The stack management,
threading, and runtime contain aspects that differ enough from the
execution model GDB expects that they can confuse the debugger, even
when the program is compiled with gccgo. As a consequence, although
GDB can be useful in some situations, it is not a reliable debugger
for Go programs, particularly heavily concurrent ones. Moreover, it is
not a priority for the Go project to address these issues, which are
difficult. In short, the instructions below should be taken only as a
guide to how to use GDB when it works, not as a guarantee of success.

Carbide does not include debugging info for some files

In Carbide 2.0.2, if I set active configuration to be "Phone Debug GCCE", build the project, go to Debug perspective, choose "Executables" tab, and select the executable file, Source File Name/Location window will list all the files I am able to use while debugging.
The problem is that the list does not contain all files from the project, even though their code is successfully linked and executed on a device. As a consequence of the issue, I am not able to set break points in these files.
What is the catch and how can I fix it?
Thank you.
This is a problem with the version of GCCE that is used by default with Symbian. It has a number of bugs with debug information, including sometimes missing line information for some files.
The alternatives are (a) the commercial RVCT compiler, or (b) follow the in-progress work to move to a newer GCCE compiler. A good start for that is here:
http://developer.symbian.org/wiki/index.php/The_GCCE_toolchain_initiative