I am already setting the 3rd party code files as libraries in my project, but I am still getting messages from those files (libraries) in the Global Wrap-up in the PC Lint output file. Is there a way to suppress the messages from the libraries in the global wrap-up? I am using PC Lint v9.00
PC-Lint parses source files tagged as "library" the same way like normal source files but applies a different warning threshold. The option -w controls the warning threshold for normal files while -wlib controls the warning threshold for libraries. A typical setup would use -w3 for own code and -wlib(1) for library code.
With -wlib(1) PC-Lint still reports various major errors regarding library code, which is a good idea because these messages are often related to configuration errors of the PC-Lint project and not the library code itself.
Still it is quite common for 3rd party code to contain code that invokes PC-Lint warnings even at -wlib(1). In this case there are several solutions possible:
Turn off all warnings in Library code with -wlib(0). This might hide errors related to the project setup though.
Turn off the remaining library-related messages by using the option -elib(<x>) for each error code. In contrast to -e<x> using -elib<x> disables the error message for the library code only.
I would like to recommend the second solution unless you have to cope with a really high number of messages.
Related
So I am in a bit of a pickle here and am at my wits end.
Issue:
I have made some lua C module that target another package's C++ shared library. Attempting to require the Lua module fails due to a dependency issue. I can find the module shared library just fine but when the linker attempts to find the library I need to link against, I get an error that looks like:
/usr/bin/lua: error loading module 'mytest' from file '/usr/lib/lua/5.3/mytest.so':
Error loading shared library libmy_test.so: No such file or directory (needed by /usr/lib/lua/5.3/mytest.so)
The directory structure used for linking is
|-usr
|--lib
|---lua
|----5.3
|-----mytest.so
|-mockfs
|--usr
|---lib
|----libmy_test.so
My LUA_CPATH is:
/usr/lib/lua/5.3/?.so;/mockfs/usr/lib/?.so;
My LD_LIBRARY_PATH is:
/mockfs/usr/lib/
What is driving me mad is that when the libmy_test.so is in the same directory as mytest.so, there are no problems. But due to other restrictions I cannot modify the path of libmy_test.so or add a symlink without substantial refactoring and lag time for builds/regressions. I'm unsure of where to even continue here because it is definitely a "searching for the library" problem but I don't know how to get insight into what is going on under the covers to fix the issue.
Adding /mockfs/usr/lib/?.so to LUA_CPATH is not going to help, as it only works for Lua modules loaded with require (which already works in your case for mytest.so) and doesn't work for loading their dependencies (which should be handled using dynamic linking).
It's not clear if LD_LIBRARY_PATH is even used in your case; I'd set LD_DEBUG=all to get LD troubleshooting information, which should tell you what is or is not being loaded and why.
Also, even if you can't put libmy_test.so where mytest.so is located, you can still put mytest.so where libmy_test.so is and configure LUA_CPATH like you have to try making it work that way.
So this will be unrelated to other people's Lua code. This problem description is slightly abstracted from reality as there is a lot of internal tooling from my company in front of it. I followed Paul's answer to try and get more information, LD_DEBUG was working up until I called my Lua script. Then the linker would stop giving me any information even though the require was still failing with the same error.
After a LOT of digging and my personal discovery of strace I managed to identify that the linker being used when calling require was in fact using "LD_PATH" to search for libraries instead of "LD_LIBRARY_PATH". Why this was? I still have no idea other than maybe an intentional design decision to combat some of the limitations of our internal tooling when doing cross compilation.
For anyone who experiences linker issues with Lua, LD_DEBUG and strace are very nice utilities for running down your issues.
i have compiled and installed igraph according to the documentation and no errors occurred, additionally i can use and compile the library just fine (I use CLION). No the code completion does not work for some of the functions, they seem to be quite basic functions. So I checked if my IDE know the header files installed, located in /usr/local/include/igraph (i use CentOS). It knows them, so i used grep to search through them to find e.g. igraph_vector_init, and it is nowhere to be found! No of course I would like the code completion to work and I am at a loss since the appropriate header files do not seem to contain the declarations of often-used functions! Is this a problem with my build? I also checked the online repository, without avail. Additionally I checked that the examples (which use the functions) and the documentation match the version, they do. What could I possibly miss?
I am looking for something similar to the JavaScript linting tools JSHint or JSLint for C. My text editor (Sublime Text 2) has a JSHint pluggin that gives me real time feedback to my JavaScript code.
What is the best way to get feedback about the quality of my C code? Are there any tools that could give me real time linting?
I've concocted a way to drop some user-made linters written for SublimeText 2 into the mix to get the linting working with SublimeLinter and ANSI C. Also note, this is a slightly 'hacky' way of getting it to work.
You must have clang installed (for OS X you can use Apple's command line tools to install clang/the LLVM compiler, which requires only a developer account, which is free), you also must have SublimeLinter installed in Sublime Text 2
Navigate to this user's fork of SublimeLinter and proceed to download the 'c.py' module from the modules folder
Copy this module into SublimeLinter's working modules directory located under **your SublimeText 2 data directory**\Packages\SublimeLinter\sublimelinter\modules\ (see this for further information on the data directory)
Restart Sublime Text 2†
†Be sure that the current language in the lower right-hand corner of the window is set to 'C', not 'C++', 'Python', ect.
Take a look at the Clang Static Analyzer and Gimpel's PC-lint and FlexeLint
Also, please have a look at cppcheck
Since this question was asked and answered, there are now some options for C/C++ linting in Sublime that are a bit more user friendly than the accepted answer. All of these are plugins for SublimeLinter. I recommend using Package Control as a package manager for Sublime Text (as do the plugin authors).
First, install Sublime Linter if you don't already have it (it's a pretty popular linting framework for multiple languages). It is most easily installed through package control, as the authors recommend, but more info is on the github site. Once Sublime Linter is installed, there are two to four different accessory packages that now exist for linting C and C++ code.
Two of these use the C/C++ compiler itself for checking; these are SublimeLinter-gcc and SublimeLinter-clang. Both can be installed via Package Control, and provide SublimeLinter with an interface to the relevant underlying compiler. The gcc package makes it easy to specify which compiler executable you want to use, in case you might want to check code for cross-compilation.
The other two are interfaces to cpplint and cppcheck, respectively. These two are also available on Package Control, and despite the names it seems that both will lint C and C++ code.
Note that you probably only want one of these options enabled at a time, although the SublimeLinter setup allows you to have multiple options installed and only one enabled via the "linters": {...} option stanza.
Passing it through your compiler with full warnings is a pretty good basic lint. It will catch things like typoed variables and such. clang with optimizations off is fast enough to use as the basis of a real-time plugin, but I'm not aware of such for sublime text.
You have enough rep that I feel this might be too obvious of a suggestion, but it sounds like you would basically benefit from an IDE? e.g., Eclipse. I dev in Eclipse/Java and it's pretty aggressive regarding errors/warnings, certainly more than I've seen a compiler be.
When I link to the one under Release/ ,got a fatal error:
LINK : fatal error LNK1146: no argument specified with option '/machine:'
Then I tried to link to the .lib under Debug/ and this time it works.
But what can be different?
Usually, no optimization is done to debug assemblies, while release assemblies are optimized. Debug assemblies will also often contain cruft like source file line numbers.
This isn't actually a C question; it relates to the platforms used.
Frequently, a project/solution will be set up to create a version for debugging and one for release, and putting them in Debug/ and Release/ directories is a common way to distinguish. The debug version will typically compile fast and run slowly, and contain information to link the internal execution to the source code (such as line numbers and variable names). The release version is typically slower to compile and faster to run, and it's much more difficult to track what's going on inside.
Obviously, there have to be differences between the debug and release versions, if only the appropriate compiler flags. However, in the build systems I'm familiar with, it's possible to make arbitrary other changes, and sometimes this will cause a release-version-only bug, which is a pain. Alternately, if the C code doesn't specify the behavior properly, the debug and release versions might interpret it differently, and that's also a pain.
In this case, I'd guess that there was a difference in how they were built. I can't really comment further without more information.
What is the OS? What is the C compiler used? What build system do you use (if you're using an IDE, possibly the one standard with the IDE)? What is the library you're using. Does your organization build it, or do you get it from outside? Knowing these things would give us a clue as to where to start looking.
You may want to change the build configuration for debug and release versions seperately.
I am using splint for code checking, and it is throwing out a huge number of warnings. Some of them, I guess can be ignored. I am in the process of creating the .splintrc by trial and error.
My question,
Is there some sample .splintrc file that can be used?
I am using splint for C code, written for a multi-tasking embedded system.
This may not be the greatest of help but I think that you need to provide a bit more information about the type of error messages that you are getting and the target processor/compiler that you are using. The different compilers for embedded target processors all have their own syntax to provide their specific functionality (interrupt processing, transferring to supervisor modes and hardware interfacing are examples)
I have tried to use splint on the MSP430 under IAR and gave up because of the number of warnings and errors that it was throwing when it tried to process the compiler supplied hardware interface definition files. I bit the bullet and purchased Gimpel LINT which came with some configuration files that I could modify to support the precise flavour of compiler and processor I was using.
I have never worked with Splint, but have worked with PC-Lint, and this was my experience as well. Without the compiler configuration files, the lint tool will throw a ton of errors.
You will need to find or create compiler-specific configurations files for your compiler informing the linting tool of the special (non-standard) C constructs and macros that it uses which should be ignored by the linting tool, or you will continue to throw tons of errors.
It is worth the effort, however. Linting your code will help you find errors now instead of during testing when they are harder to find and much more expensive to fix.