I am new to QAC stuff and I am trying to set up QAC on my project. I am currently encountering this error when I try to run QAC on a file.
C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.2\arm\inc\c\intrinsics.h ### 26 ### 869 ### [Q] '#error' directive: "Unknown compiler intrinsics version" Analysis terminated due to '#error' directive. ### 9
I have set the compiler personality file to not include the warnings from the folder above, but I am still seeing this error. Please kindly help on how to overcome this issue.
In general it is not a good idea to apply static analysis to headers provided with the compiler as they are tuned to the compiler in question and can contain any number of specialized constructions. In fact they may not even compile with another compiler and this is completely OK.
As an answer to the problem at hand, it looks like your static analysis tool is missing some of the macros that are predefined in iccarm. One way to solve this problem is to use the --predef_macros command line parameter to have the compiler output a file containing all predefined macros (as C source code). The content of this file can be used to set up the static analysis environment.
Related
sorry I know it is repeated and it is similar to this question but there was only one answer which doesn't satisfy the objective :)
The compilation of uamqp library is pretty easy. I end up with 2 static libraries to be used when linking in my project in eclipse. During run time and if an error happens, the error message shows the path, where the static libraries are originally compiled. I get something like this:
Error: Time:Tue May 22 09:04:45 2018 File:/home/hostname/azure-uamqp-c/src/saslclientio.c Func:on_underlying_io_error Line:243 Error callback received in unexpected state
I have no problem with the error message. The issue is only when the error occurs, then it shows the path /home/hostname/azure-uamqp-c/saslclientio.c
Please how can I compile the uamqp library, so that no absolute paths are stored inside? is it a cmake command option that I do have to configure?
Thanks
Message "Error callback received in unexpected state" is emitted by LogError() call, and LogError macro eventually uses preprocessor expression __FILE__ for refer to the path of source file.
According to that answer, expression __FILE__ is expanded to path, which is passed in compiler's command line.
Unfortunately, CMake always uses absolute paths for source files when pass them to the compiler. So there is no easy way for generate relative paths in logs.
You may write a wrapper around compiler, which transforms absolute paths to relative and calls compiler.
I am attempting to build a project that comes with an automake/autoconf build system. This is a well-used project, so I'm skeptical about a problem with the configure scripts, makefiles, or code as I received them. It is likely some kind of environment, path, flag, etc problem - something on my end with simply running the right commands with the right parameters.
The configuration step seems to complete in a satisfactory way. When I run make, I'm shown a set of errors primarily of these types:
error: ‘TRUE’ undeclared here (not in a function)
error: ‘struct work’ has no member named ‘version’
error: expected ‘)’ before ‘PRIu64’
Let's focus on the last one, which I have spent time researching - and I suspect all the errors are related to missing definitions. Apparently the print-friendly extended definitions from the C standard library header file inttypes.h is not being found. However, in the configure step everything is claimed to be in order:
configure:4930: checking for inttypes.h
configure:4930: /usr/bin/x86_64-linux-gnu-gcc -c -g -O2 conftest.c >&5
configure:4930: $? = 0
configure:4930: result: yes
All the INTTYPES flags are set correctly if I look in confdefs.h, config.h, config.log Output Variables, etc:
HAVE_INTTYPES_H='1'
#define HAVE_INTTYPES_H 1
The problem is the same whether doing a native build, or cross-compiling (for arm-linux-gnueabihf, aka armhf).
The source .c file in question does have config.h included as you'd expect, which by my understanding via the m4 macros mechanic should be adding an
#include <inttypes.h>
line. Yes, as you may be inclined to ask, if I enter this line myself into the .c file it appears to work and the PRIu64 errors go away.
I'm left with wondering how to debug this type of problem - essentially, everything I am aware of tells me I've done the configure properly, but I'm left with a bogus make process. Aside from trying every ./configure tweak and trick I can find, I've started looking at the auto-generated Makefile.in itself, but nothing so far. Also looking into how I can get the C pre-processor to tell me which header files it's actually inserting.
EDIT: I've confirmed that the -DHAVE_CONFIG_H mechanic looks good through configure, config.log, Makefile, etc.
autoconf does not automatically produce #include directives. You need to do that on your own based on the HAVE_* macros. So you'll have to add something like this:
#ifdef HAVE_INTTYPES_H
# include <inttypes.h>
#endif
If these lines show up in confdefs.h, a temporary header file used by configure scripts, this does excuse your application from performing these #includes. If configure writes them to confdefs.h, this is solely for the benefit of other configure tests, and not for application use.
First, run make -n for the target that failed. This is probably some .o file; you may need some tweaking to get its path correctly.
Now you have the command used to compile your file. If you don't find the problem by meditating on this command, try to run it, adding the -E to force preprocessor output text instead of invoking the compiler.
Note that now the .o file will be text, and you must rebuild it without -E later.
You may find some preprocessor flags useful to get more details: -dM or -dD, or others.
I am trying to write a Linux kernel module with CLion. This is the cmake file:
cmake_minimum_required(VERSION 3.5)
project(labs)
set(KERNEL_HEADERS
/home/alex/Developer/linux/include
/home/alex/Developer/linux/arch/x86/include
/home/alex/Developer/linux/arch/x86/include/generated
/home/alex/Developer/linux/include/uapi
/home/alex/Developer/linux/include/generated/uapi
/home/alex/Developer/linux/arch/x86/include/uapi
/home/alex/Developer/linux/arch/x86/include/generated/uapi
)
set(MY_MODULE_SOURCES
chapter_03/lab_01/hello.c
)
add_definitions(-imacros /home/alex/Developer/linux/include/linux/kconfig.h)
add_definitions(-D__KERNEL__)
add_definitions(-DMODULE)
add_definitions(-std=gnu89)
include_directories(${KERNEL_HEADERS})
add_custom_target(labs COMMAND $(MAKE) -C ${labs_SOURCE_DIR}
PWD=${labs_SOURCE_DIR})
add_library(dummylib ${MY_MODULE_SOURCES})
The actual building of the kernel module is done with the externally called makefile using "add_custom_target". The "dummylib" is only there so that CLion actually starts to parse the header files and gives me auto completion. With my supplied definitions it does even compile the "dummylib" successfully (look at the screenshot). It is no kernel module though, but that does not matter ;)
My problem is the error you see in the screenshot. Somehow it says that it can't resolve all the macros defined in the kernel headers. Functions, structs and plain defines ( "MODULE_SIG_STRING ") do work (as you see). I do not understand why the editor says it cannot resolve the macro but can still build it. What is more strange is that I can even jump to the declaration using STRG+B of the marked macros. Clearly something is going wrong. The macros are really defined within linux/module.h.
Update
When I set -std=c89 instead of -std=gnu89 the editor recognizes the macros but the "dummylib" of course fails to build since the kernel needs the gnu extensions. I guess this is a bug in CLion. I posted it at the Jetbrains Bugtracker: https://youtrack.jetbrains.com/issue/CPP-6875
I am trying to use the following method to include a project header file:
#include FILE_PATH
Where FILE_PATH is defined as the file to be included.
The project compiles without errors if FILE_PATH is include as:
#define FILE_PATH "hal/micro/config.h"
#include FILE_PATH
But if FILE_PATH is pre-defined as a compiler define option inside the project options, then building the project returns the following error:
Error #13: Expected a file name
The development software being used is Code Composer Studio version 6.
What am I missing here to pre-define the header file path in a project?
Additional Details:
I am in the process of converting a working project from the IAR embedded workbench IDE to Code Composer Studio. The Pre-define NAME (--define, -D) shown in the picture below are mostly identical to how they were in the IAR project.
The pre-define name boxed in red is currently the cause of the error, but this could occur with any of the other defines with file pathnames.
I have tried the suggestion of using the #ifdef statement to at least verify that PLATFORM_HEADER is actually defined and it does seem to be defined. I also checked for typos and there doesn't appear to be any noticeable typos.
The key reason for wanting to go with the pre-defined macro approach is to avoid individually making changes to numerous files affected by this error.
I still have not yet tried a command line compile, since I need to reference the manual on how to do so, but I will try as soon as I figure it out.
#StenSoft wrote:
The IDE does not correctly escape the parameters. You should escape the quotes. You can also try placing PLATFORM_HEADER somewhere in the code and see what the compiler would tell you it sees.
I am using Visual studio 2010 for building C project. My project contains a number of header files,source file and parsers. It uses lex and bason files. I am getting a single error during the compilation and íé the following
abc.y:error C2065: 'INPUT' : undeclared identifier
I tried the solutions I am getting like including
#define WIN32_WINNT >= 0x0501
in my main.c file before the inclusion of any of the header files.I am not able to get rid of this error. Could you please let me know what Can be the reasons for this error?
EDIT
The snippet of code that is showing error is:
list_Cons(0, list_List((POINTER)INPUT)
The surprising thing is that If i alter INPUT into INPUT1, I get the same error. It is stoic to change.
Presumably you read this and this.
#define WIN32_WINNT >= 0x0501 wont work. You should try using #define WIN32_WINNT 0x0501 instead.
Also, check that you are actually #including winuser.h
A C++ compiler cannot process a *.y file. For that you need a yacc / bison program, which does not come included with Visual Studio 2010.
For myself I use CMake which can generate MSVC projects along with other build types. You can tell it that a .y needs to be processed outwith the C/C++ files and it will instruct MSVC to invoke whatever external tools are necessary to preprocess the non-C/C++ parts.