I am using the clang compiler on windows. I used the installer from the LLVM website. Sometimes it gives me a compiler error.
clang -I./include main.c CoreFoundation.dll
it gives:
In file included from main.c:4:
In file included from ./include\CoreFoundation/CFNumberFormatter.h:110:
./include\CoreFoundation/CFXMLParser.h:159:81: error: unknown type name 'CFXMLNodeRef'
typedef void * (*CFXMLParserCreateXMLStructureCallBack)(CFXMLParserRef parser,
CFXMLNodeRef nodeDesc, void *info);
...
and sometimes this..
In file included from main.c:4:
In file included from ./include\CoreFoundation/CoreFoundation.h:86:
./include\CoreFoundation/CFDateFormatter.h:104:105: error: unknown type name 'CFDateRef'; did you mean 'CFDataRef'?
CFStringRef CFDateFormatterCreateStringWithDate(CFAllocatorRef allocator, CFDateFormatterRef formatter, CFDateRef date) AVAILABLE_MAC_OS_X_VERSION_10_3_AND_LATER;
...
...and other similar warnings, seemingly randomly choosing where to stop. Sometimes it compiles through without error. When it gives an error, they seem to be be about not finding a symbol from an included file. It doesn't complain about not finding the file. But it doesn't consistently stop at the same point and sometimes compiles successfully.
I can reproduce this "error" under Linux with gcc. I even get the "report this compiler bug pls" message.
When it gives an error, they seem to be be about not finding a symbol from an included file
You can get this:
if you compile with multiple threads (eg. make -j8)
if you abort the compile and then start it again without "cleaning" all obj files
if you compiled your source, changed something and compile without "cleaning"
if your compiler/make/build process changes the order every time... (had this with cmake and opencv 3 source)
Related
I'm trying to run clang-tidy on my IAR project, but I would like to ignore system header files. I tried the solutions provided here but they didn't work (read on for the results). Here's my project structure:
Proj
----Src
----Inc
SysHdrs
And this is my clang-tidy command from inside Proj:
clang-tidy.exe Src/*.c -header-filter=Proj\\Inc\\.* -checks=* -- -I"abs/path/to/Proj/Inc" -isystem"abs/path/to/SysHdrs"
I'm getting warnings on my Src files, as well as on some SysHdrs files such as SysHdrs/DLib_Defaults.h and SysHdrs/yvals.h. For example:
abs/path/to/SysHdrs/DLib_Defaults.h:563:6: error: "Compiler must support __weak" [clang-diagnostic-error]
#error "Compiler must support __weak"
^
abs/path/to/SysHdrs/yvals.h:37:4: error: "DLib compiled with wrong (version of IAR) compiler" [clang-diagnostic-error]
#error "DLib compiled with wrong (version of IAR) compiler"
^
abs/path/to/SysHdrs/yvals.h:232:11: error: unknown type name '__WCHAR_T_TYPE__' [clang-diagnostic-error]
typedef __WCHAR_T_TYPE__ _Wchart;
abs/path/to/SysHdrs/yvals.h:358:3: error: expected identifier or '(' [clang-diagnostic-error]
__WEAK __ATTRIBUTES void __iar_Locksyslock_Malloc(void);
^
Note that I do need to supply the system headers to clang, because otherwise it'd complain about a missing stdio.h / string.h etc.
As far as I know the -header-filter should filter out whatever doesn't match the regex pattern, so my system headers shouldn't be included in the outuput. Further, I've explicitly set the SysHdrs as "system headers" by using the -isystem identifier.
I even tried -header-filter=main\.h and it still processes the system headers.
Anything else I can try?
I made C/C++ source code modification tool using Clang Libtooling. I ran into the following error while executing my tool on test programs.
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
But I would like for the tool to ignore this limit, print all the errors, and execute AST modification as normal. Is there a way to fix this problem using Clang Libtooling?
Thanks to #dratenik, I solved the problem by adding an ArgumentAdjuster which passes Clang the option -ferror-limit=0.
clang::tooling::ClangTool tool(compileDb, filename);
tool.appendArgumentsAdjuster(clang::tooling::getInsertArgumentAdjuster(
"-ferror-limit=0"));
tool.run(...);
I am facing quite a strange situation trying to build a mixed-language dynamic iOS framework with Bazel.
The source code of the framework consists of *.c, *.cpp, *.m, *.mm, *.h, *.hpp files.
My first naive attempt was to declare a single objc_library rule referencing all the sources. That failed with an error message reading something about conflicting rules. Then I declared four distinct objc_library rules for *.m, *.mm, *.c, and *.cpp files respectively, and then referenced all these four rules as dependencies for the final ios_framework rule.
At this point, everything compiled and linked just fine (barring several compiler warnings which were expected). However, now the black magic begins:
The static library resulting from compiling ObjectiveC++ sources does contain all the necessary symbols (verified with the "nm" tool)
The .apple_binary_lipobin file resulting from the linking phase does not contain symbols from ObjectiveC++ sources
I believe I carefully went through the command lines used for compiling and linking, both for Bazel and xcodebuild.
The only anomalies I was able to spot:
xcodebuild passes a -single_module argument when linking, while Bazel cross tool does not.
Bazel cross tool adds '-stdlib=libc++' '-std=gnu++11' command line arguments when invoking wrapped_clang_pp during linking, while xcodebuild does not pass these arguments. I guess Bazel does this because there're these lines in the default Apple CROSSTOOL:
action_config {
config_name: "objc++-executable"
action_name: "objc++-executable"
tool {
tool_path: "wrapped_clang_pp"
execution_requirement: "requires-darwin"
}
flag_set {
flag_group {
flag: "-stdlib=libc++"
flag: "-std=gnu++11"
}
but I am not sure if these flags are really needed when invoking the linker.
I must admit I've run out of ideas except for trying to patch the CROSSTOOl file to make it behave as close as xcodebuild as possible.
Please help.
Can you try adding alwayslink = 1 to the objc_library target containing the C++ symbols? The linker is deadstripping the C++ symbols as they are not being referenced anywhere in the binary.
I tried building the first example here and got errors. Right on the first line there's a missing include statement, but I managed to figure out it should be
#include "hdf5.h"
But even after fixing that I got more errors:
$ h5cc ./example1.c
./example1.c: In function ‘main’:
./example1.c:66:4: error: too few arguments to function ‘H5Dcreate2’
In file included from /usr/include/hdf5.h:27:0,
from ./example1.c:6:
/usr/include/H5Dpublic.h:104:14: note: declared here
Any idea how to solve it?
The example code was written for release 1.6 of hdf5, and as such will simply not compile on a 1.8 release without modification.
If you want to get the code to work on 1.8, you need to enable 1.6 compatibility, which means passing in the flag:
-DH5_USE_16_API
to the h5cc command line like:
h5cc -DH5_USE_16_API ./example1.c
and it should compile correctly; otherwise you will have to rewrite the code to make use of the 1.8 API.
I am new to static checking and I am assigned a task to do static checking of C code. I am given the liberty to select any one tool keeping in mind that the organisation already uses lint so a lint based tool should be preferred.
I selected splint because it is a free software. (PC lint and Lint being commercial)
Now I tried compiling a simple C file which had #include <unistd.h>
Splint shows error:
/usr/include/unistd.h:221:26: Parse Error:
Suspect missing struct or union keyword: __ssize_t :
int. (For help on parse errors, see splint -help parseerrors.)
Cannot continue.
How can I get this working?
I read in some places that splint doesn't support C99 standard whereas some says it supports. Can anyone tell me whether I should reconsider my choice as I will be using C99 format. What are the other free alternatives which are very similar to lint/splint?