We are using a PVS Studio (free variant for opensource projects) in conjunction with travis-ci and it for some reason spawns errors for files located in /usr/local/clang-3.5.0/lib/clang/3.5.0/include:
/usr/local/clang-3.5.0/lib/clang/3.5.0/include/stddef.h:58:1: warning: V677 Custom declaration of a standard 'size_t' type. The declaration from system header files should be used instead.
/usr/local/clang-3.5.0/lib/clang/3.5.0/include/stddef.h:86:1: warning: V677 Custom declaration of a standard 'wchar_t' type. The declaration from system header files should be used instead.
/usr/local/clang-3.5.0/lib/clang/3.5.0/include/stdarg.h:30:1: warning: V677 Custom declaration of a standard 'va_list' type. The declaration from system header files should be used instead.
/usr/local/clang-3.5.0/lib/clang/3.5.0/include/stddef.h:47:1: warning: V677 Custom declaration of a standard 'ptrdiff_t' type. The declaration from system header files should be used instead.
This location looks like an example of “system” headers for non-standard compiler and is far away from the project root (which AFAIR is somewhere in /home: standard travis location). Script run uses latest version from https://www.viva64.com/en/pvs-studio-download-linux/, latest run at “Mon Jul 3 20:13:42 UTC 2017” (unfortunately, used version is not saved).
If the compiler is located in some unusual place, it is recommended to add a new path to the analyzer exceptions, so that you can see in the report only the warnings for the code of your own projects.
pvs-studio-analyzer analyze ... -e /path/to/exclude-path ...
or
pvs-studio ... --exclude-path /path/to/exclude-path ...
It appears that PVS does not detect the error if clang is updated to clang-4.0.
Related
I try to build large project with many directories and sub-directories, some of them are being used to create different libs.
using GNU make using same compilation flags. most of the folder are successfully built, but in a specific folder the build failed, and it gets many errors that some definitions is missing.
For instance, the first error is:
In file included from /usr/include/c++/4.8.2/cwchar:44:0,
from /usr/include/c++/4.8.2/bits/postypes.h:40,
from /usr/include/c++/4.8.2/iosfwd:40,
from /usr/include/c++/4.8.2/memory:72,
...
/usr/include/wchar.h:614:9: error: ‘__gnuc_va_list’ has not been
declared
__gnuc_va_list __arg
)
this error comes from simple #include at of the files in this lib, but same sort of error happens for any file and for different standard library headers.
The strength thing is that this project was completely successfully built before i pulled some updates from remote repository. at this merge no changes were done to this file.
Tried to use
g++ -E /usr/include/wchar.h | grep __gnuc_va_list | head -1
result is:
typedef __builtin_va_list __gnuc_va_list;
As i see at this answer, __builtin_va_list shuould be created by gcc, and it probably did create it- otherwise many other files were failed to compile
I can't understand why it happens and why only at this folder/lib.
I had same problem for libhydrogen on windows and mingw 5.3.0, you can just define it to:
typedef void* __gnuc_va_list;
... then it compiled and the delivered tests.c worked.
i think for unix systems its (unsure):
typedef char* __gnuc_va_list;
I am trying to invoke an existing COBOL application using JNI. COBOL application structure is as follows.
c-wrapper(main)-->COBOLProgram -> several dyn(.so) and static called modules
The existing COBOL application involves several statically called subprograms(COBOL) and many dynamic(COBOL) ones.
Jni invocation of the application is ok, but it could not locate and invoke COBOL dynamic sub modules.
Modified Application structure (for jni) is as follows:
java class --> libjni.so --> appl.so
I verified COB_LIBRARY_PATH and LD_LIBRARY_PATH environment variables before the CALL, those seems to be fine.
Following error message got in the case dynamic modules.
libcob: ....<module>.so: undefined symbol: cob_save_call_params
I use 64 bit , 1.1.0 on linux. gcc is used to create binary using the c output of cobc command
This issue can be resolved by properly specifying -lcob linkage option(when using gcc). The gcc command used to create the binary already contained the option, but it was mistakenly placed in between target and source file, which was not in effect. Execution of dll without JNI invocation, somehow does not require -lcob option, but from the JNI invocation requires -lcob linkage option.
I'm trying to compile the MultiBoost Library with C++11 but I can't make it work. The problem seems to be with the BZip2 Library that is used internally. More specificly there is a wrapper called Bzip2Wrapper to provide a c++ interface to the C library. All the files of the C library are included in the same folder. When using the default make file everything works but when I change
project(multiboost)
to
project(multiboost CXX)
I get the following errors:
libMultiBoostLib.a(Serialization.cpp.o): In function `Bzip2WrapperReader::open(char const*)':
Serialization.cpp:(.text._ZN18Bzip2WrapperReader4openEPKc[_ZN18Bzip2WrapperReader4openEPKc]+0x97): undefined reference to `BZ2_bzReadOpen'
Serialization.cpp:(.text._ZN18Bzip2WrapperReader4openEPKc[_ZN18Bzip2WrapperReader4openEPKc]+0xc5): undefined reference to `BZ2_bzReadClose'
libMultiBoostLib.a(Serialization.cpp.o): In function `Bzip2WrapperReader::close()': ...
The CMakeList file looks like this
# Bzip2
file(GLOB bzip2_SRCS "${BASEPATH}/Bzip2/*.cpp" "${BASEPATH}/Bzip2/*.c" "${BASEPATH}/Bzip2/*.h")
add_library(Bzip2Lib STATIC ${bzip2_SRCS})
#add_library(bzip2 SHARED ${bzip2_lib_SRCS})
...
# adding library to the exec
target_link_libraries(multiboost MultiBoostLib Bzip2Lib)
Any ideas what could go wrong? I don't even know what the problem is.
Thanks!
This does not look like a C++11 error but an error in the Build system.
I have not looked at the Code, but from the output you added something like this
target_link_libraries(MultiBoostLib PUBLIC Bzip2Lib)
should add the missing dependency from libMultiBoostLib on libBzip2Lib.
I found the problem. I was adding "CXX" to my project description which disabled the use of C. Therefore the libraries (in C) could not be compiled. Changing it to "project(name C CXX)" solved this issue. I then also needed to include the line "set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")" to enable C++11 support. Now everything is working.
Thanks a lot!
I am having liavcodec.a static library and header files of this library.
libavcodec.a
I added this library and their header files into my project and there is no error. I can see this library added in Target->Info->General and i have edited the Header Search Path also.
I can add header file #import “avcodec.h” into xcode project also. I can use all the variables which have been declared in structure of that file. But i am trying to use any function from that class, i am getting some errors like,
Test.m
—-
“-avcodec_register_all”, referenced from:
-[Test initialize] in Test.o
Symbol(s) not found
collect2: id returned 1 exit status
—-
Do you what is the problem?
Many thanks.
Provide implementation of your [test initialize] method. Also provide the configuration command which you used to build the static library.
Try rebuilding the library, the method avcodec_register_all should be directly accessible through allcodecs.c file if the library is included in target and header search path is properly configured. Probably the library is corrupt, just as tedge says.
Just as a sanity check, verify that your library file contains the expected symbols; Type this in a terminal window (replacing path/to with the correct path):
nm -g /path/to/libavcodec.a | grep avcodec_register_all
(If the command's output is just a blank line, then the library file is probably corrupt).
I was wondering if there is an Xcode or GCC preprocessor symbol for the target name of the application.
For example if I'm building an application called "MonkeyChicken", is there a preprocessor symbol such that
printf( __TARGET_NAME__ )
outputs:
MonkeyChicken
I don't believe there is any built-in (gcc has no idea what you're building when you compile a file), but you can always create one using GCC_PREPROCESSOR_DEFINITIONS in an xcconfig file (you are using xcconfig, right?) Something like this should work as you indicate above:
GCC_PREPROCESSOR_DEFINITIONS = __TARGET_NAME__=\"$(PRODUCT_NAME)\"