The Coverity Scan Build Tool fails to compile any C file that includes <stdlib.h> on Ubuntu 18.04 when _GNU_SOURCE is defined:
$ cat > main.c
#include <stdlib.h>
int main() {
}
$
$ gcc -D_GNU_SOURCE=1 -o main main.c
$
$ /opt/cov-analysis/bin/cov-build --dir cov-int gcc -D_GNU_SOURCE=1 -o main main.c
Coverity Build Capture (64-bit) version 2017.07 on Linux 4.15.0-20-generic x86_64
...
[WARNING] Emitted 0 C/C++ compilation units (0%) successfully
...
$
The same build works perfectly on Ubuntu 16.04 or without _GNU_SOURCE defined:
$ /volatile/local/cov-analysis/bin/cov-build --dir cov-int gcc -o main main.c
Coverity Build Capture (64-bit) version 2017.07 on Linux 4.15.0-20-generic x86_64
...
Emitted 1 C/C++ compilation units (100%) successfully
...
$
How to get Coverity Scan to build C sources with _GNU_SOURCEdefined on Ubuntu 18.04?
For those interested file cov-int/build-log.txt can be found here:
https://gist.github.com/DimitriPapadopoulos/0dcd9018eed26401cc6095087d9cc1d5
After contacting Coverity support, it appears this is known bug. They suggested I work around it by switching from the default Ubuntu 18.04 compiler (GCC 7) to the previous version (GCC 6):
sudo apt install gcc-6
Indeed _Float32, _Float32x, _Float64, _Float64x and _Float128 were introduced in GCC 7.
Coverity is failing to define the types GCC would define, but then it's claiming to be GCC anyway. Here's a workaround: https://gist.github.com/vathpela/0cede6d6eb5b0ec0791c6afc4282c340#file-fix_coverity-h
Just be sure you do:
#include "fix_coverity.h"
before stdlib.h gets included, whether directly or indirectly.
Related
I am trying to compile code on the raspberry pi 4 using ubuntu server 20.04.1 LTS. I am using gcc to compile it and every time I try and run the file after it gets compiled successfully it says
-bash: ./out: cannot execute binary file: Exec format error
When I do the file command on out I get, and I know that the ARM cpu is 64bit
out: ELF 64-bit LSB relocatable, ARM aarch64, version 1(SYSV), not stripped
This is the source that I am trying to run
#include <stdio.h>
#include <stdlib.h>
int main(){
printf("Hello World!");
return 0;
}
This is the gcc command I am running
gcc -march=native -ctest.c -oout
It's a "LSB relocatable" file, which is not executable since it hasn't been linked because the -c in your command command gcc -march=native -ctest.c -oout stands for "compile and assemble only, do not link":
$ gcc --help
<...>
-c Compile and assemble, but do not link.
<...>
You should compile everything into an executable:
gcc -march=native test.c -o out
I have downloaded and installed clang on windows 10 from http://releases.llvm.org/download.html
and mingw from https://sourceforge.net/projects/mingw-w64/
I am trying to compile a very basic C program using clang/lld/mingw:
int main(int argc, char* argv[argc + 1])
{
return 0;
}
To compile I invoke:
clang.exe -target x86_64-windows-gnu -fuse-ld=lld.exe -g -gcodeview -Wl,/debug,/pdb:example.pdb example.c -o example.exe
This creates an exe which faults on startup in mainCRTStartup (__security_init_cookie to be precise).
However, running with default ld from binutils is successful:
clang.exe -target x86_64-windows-gnu example.c -o example.exe
Please note that I wish to use mingw headers, not msvc.
In total I tried:
x86_64-8.1.0-posix-seh-rt_v6-rev0
x86_64-7.3.0-posix-seh-rt_v5-rev0
x86_64-8.1.0-win32-seh-rt_v6-rev0
x86_64-8.1.0-win32-sjlj-rt_v6-rev0
without any luck producing a functional program.
So I am wondering, is there something obvious I am doing wrong here?
EDIT:
I have also tried with msys2 to no avail. Specifically:
pacman -S mingw-w64-x86_64-clang mingw-w64-x86_64-lld
According to https://bugs.llvm.org/show_bug.cgi?id=40568
Linking against mingw import libraries from a normal mingw installation is a new feature, first present in LLD 8.
Unless wanting to compile a pre-release version of lld, have to wait for binary release of llvm 8.0.0. This will hopefully be sometime in March.
I'm new to developing for embedded systems, but I have installed arm-linux-gnueabi-gcc via the Linux Mint package manager and managed to build a few programs successfully.
I'm currently struggling with getting a program to compile using libusb. I've done the following:
Downloaded and unpacked the libusb 1.0.20 sources from https://sourceforge.net/projects/libusb/.
Compiled and installed them using the following commands:
~/Downloads/libusb-1.0.20 $ ./configure --host=arm-linux-gnueabi --prefix=/opt/ --disable-udev
~/Downloads/libusb-1.0.20 $ sudo make
~/Downloads/libusb-1.0.20 $ sudo make install
(The reason for sudo-ing the make commands was because I encountered permission problems related to removing old files.)
Copied a small sample file from somewhere on the internet:
#include <libusb-1.0/libusb.h>
#include <stdio.h>
int main()
{
int i=0;
libusb_context **c = NULL;
i = libusb_init(c);
printf("\nusing libusb.h\n");
return 0;
}
Tried to build it and run it with gcc:
~/Desktop/libtest $ gcc libtest1.c -o libtest1 -lusb-1.0
~/Desktop/libtest $ ./libtest1
using libusb.h
However, when I try to do the same with arm-linux-gnueabi-gcc, it can't find the library:
~/Desktop/libtest $ arm-linux-gnueabi-gcc libtest1.c -o libtest1 -lusb-1.0
/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: cannot find -lusb-1.0
collect2: error: ld returned 1 exit status
Where did I go wrong? Is there something else I need to do in order to use the library? Did I fail at compiling the library for the arm compiler? I didn't include the compiler output here since it's quite long, but there are no obvious errors. This might be a very stupid question, but I'm completely clueless.
I'm trying to use Clang static analyzer on a very simple program:
#include <stdio.h>
main ()
{
printf("Hello, world !");
}
When i do
clang helloworld.c
It compiles the program successfully.
When i do
clang -cc1 -analyze -analyzer-checker=unix helloworld.c
it raises an error:
helloworld.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^
1 error generated.
clang --analyze -Xanalyzer -analyzer-checker=unix helloworld.c
doesn't print anything.
What is the problem and how can i fix it?
I assume static analyzer doesn't see the header files though the compiler can use them.
Please, help me.
Sometimes the checker is not able to read the default include path. So you might want to pass it as an argument.
You can find the exact include path clang looks at using this command:
clang -E -x c - -v < /dev/null
and then your final query will become:
clang -I<path to include> --analyze -Xanalyzer -analyzer-checker=unix helloworld.c
Solution using -cc1 flag:
See what include paths the clang is receiving. The flag -v is the key option. The quick way of using it is the following (as given by #Nishant) along with the sample include paths it prints,
$ clang -E -x c - -v < /dev/null
...
#include <...> search starts here:
/usr/local/include
/home/codeman/.itsoflife/local/packages-live/llvm-clang6/build/lib/clang/6.0.1/include
/usr/include/x86_64-linux-gnu
/usr/include
...
On my machine, the simple use of the following command works seamlessly,
$ clang --analyze -Xanalyzer -analyzer-checker=debug.DumpCFG main.c
however the following form fails, as you pointed,
$ clang -cc1 -analyze -analyzer-checker=debug.DumpCFG main.c
For this second command (with -cc1) you can create an environment variable say MY_INCLUDES with the necessary includes. Paste the code below (with necessary include paths as per your system) into ~/.bashrc or ~/.zshrc depending on if you are using bash or zsh. (don't forget to source ~/.bashrc or source ~/.zshrc)
export MY_INCLUDES="-I/usr/local/include -I/home/codeman/.itsoflife/local/packages-live/llvm-clang6/build/lib/clang/6.0.1/include -I/usr/include/x86_64-linux-gnu -I/usr/include"
Now on bash use,
$ clang -cc1 $MY_INCLUDES -analyze -analyzer-checker=debug.DumpCFG main.c
on zsh use,
$ clang -cc1 ${=MY_INCLUDES} -analyze -analyzer-checker=debug.DumpCFG main.c
Note the use of MY_INCLUDES after -cc1 but before the main.c file. Moreover, on zsh one has to use the = prefix with the env variable or else its considered a single string (for details see this answer).
I am trying a simple example of Open MP, to parallelize a for loop, but I cannot see that the for loop is being executed on more than one core.
Here is the C program:
#include </usr/local/Cellar/gcc/5.1.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.1.0/include/omp.h>
#include <stdio.h>
#include <unistd.h>
int main() {
int n;
#pragma omp parallel
{
#pragma omp for
for(n = 0; n < 10; n++)
printf(" Thread %d: %d\n", omp_get_thread_num(), n);
printf("Number of threads: %d\n", omp_get_num_threads());
}
printf("Total number of cores in the CPU: %ld\n", sysconf(_SC_NPROCESSORS_ONLN));
}
The above code is very similar to this example.
When I execute this program and print out the total number of threads being used by it (by default it should be the total number of CPU cores), I find the result 1. Here is the output:
10:pavithran$ gcc -fopenmp openMPExample.c -o openMPExample.o
10:pavithran$ ./openMPExample.o
Thread 0: 0
Thread 0: 1
Thread 0: 2
Thread 0: 3
Thread 0: 4
Thread 0: 5
Thread 0: 6
Thread 0: 7
Thread 0: 8
Thread 0: 9
Number of threads: 1
Total number of cores in the CPU: 8
10:pavithran$
Why is it that I do not find the numbers being printed by different threads? Why is it that the total number of threads is always 1? Someone please help me in getting the parallel for loop to work.
PS: The first "#include ..." statement contains the explicit path because the simple form: #include <omp.h> does not seem to work.
You are compiling your program with Apple's clang version of gcc that does not support OpenMP. This is why you get the output
$ gcc main.c -fopenmp
main.c:1:10: fatal error: 'omp.h' file not found
#include <omp.h>
^
1 error generated.
when using
#include <omp.h>
as opposed to (the montrosity)
#include </usr/local/Cellar/gcc/5.1.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.1.0/include/omp.h>
Using the Correct Version of gcc
Note: Based on the include path I'm assuming use of Homebrew to install gcc. If that is not the case there is a section at the end on installing gcc via Homebrew with OpenMP support.
Homebrew installs gcc as gcc-4.9 or gcc-5 (for both GCC 5.1 and GCC 5.2) depending on the version you have installed. It does not create a symlink for gcc in /usr/local/bin and so when you execute gcc from the command line you will be calling Apple's clang version. This is what we must correct for and there are a multitude of ways in which we can use the Homebrew version of gcc over Apple's clang version
Explicitly execute gcc via
$ gcc-5 main.c -fopenmp
Create a symlink for gcc in /usr/local/bin with the following commands
$ cd /usr/local/bin
$ ln -s gcc-5 gcc
Now when you execute gcc -v you should see something similar to the below (providing your $PATH variable is set up correctly, see below, and you've installed gcc with OpenMP support via Homebrew, see below)
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin14.4.0/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14.4.0
Configured with: ../configure --build=x86_64-apple-darwin14.4.0 --prefix=/usr/local/Cellar/gcc/5.2.0 --libdir=/usr/local/Cellar/gcc/5.2.0/lib/gcc/5 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --with-build-config=bootstrap-debug --disable-werror --with-pkgversion='Homebrew gcc 5.2.0 --without-multilib' --with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin --disable-nls --disable-multilib
Thread model: posix
gcc version 5.2.0 (Homebrew gcc 5.2.0 --without-multilib)
Create an alias for the Homebrew version of gcc. You can do this by adding a line similar to
alias hgcc='gcc-5'
to your .bashrc or .bash_profile. What is even better is to add it to a file called .bash_aliases and then include it in your .bashrc or .bash_profile with
[[ -f ~/.bash_aliases ]] && . ~/.bash_aliases
We would then execute it via hgcc as in
$ hgcc main.c -fopenmp
Aside: Installing gcc with OpenMP support on OS X
To install gcc with OpenMP support the easiest route to take is via Homebrew. To do this you need to use the following command as per one of my previous answers
brew install gcc --without-multilib
or if you have already installed gcc via Homebrew use
brew reinstall gcc --without-multilib
This installs gcc as gcc-4.9 or gcc-5 (for both GCC 5.1 and GCC 5.2) depending on the version you have installed. It does not create a symlink for gcc in /usr/local/bin and so when you execute gcc from the command line you will be calling Apple's clang version. You can verify this by running gcc -v which should produce a similar output to the below
$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
Checking Path is Set Correctly
On (my Mac system at least) the default $PATH includes /usr/local/bin before /usr/bin as in
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
If this is not the case for you you will need to edit your .bashrc or .bash_profile and add
export PATH=/usr/local/bin:$PATH
This ensures that the Homebrew version of gcc will be found before any of the Apple versions, when we correct for Homebrew installing it as gcc-4.9 or gcc-5.
What about setting OMP_NUM_THREADS environment variable?
What would give you something like this?
> OMP_NUM_THREADS=8 ./openMPExample.o
(BTW, having a binary which name ends with '.o' might not be such a good idea)