I installed clang with Visual Studio and then built the highlighted project as it's said in the documentation.
The build was successful, however when I try this:
clang -cc1 -analyze -analyzer-checker=core.DivideZero test.c
It says:
test.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^~~~~~~~~
1 error generated.
I tried many suggestions but nothing worked.
However if I do something like this it works
clang --analyze text.c
I don't know if this uses all the available checkers. I need to write my own checker and test it...
Any ideas?
Output of clang --version
clang version 7.0.0 (trunk 322536)
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: C:\path\build\Debug\bin
Yes, I have an idea. Remove -cc1 or <stdio.h>. According to the clang FAQ this is your error. It states quite explicitly, giving your precise example:
$ clang -cc1 hello.c
hello.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^
1 error generated.
Reading on, it gives other alternative solutions, as well as a useful explanation, which you should certainly read in its entirety, since it's our job as programmers to read the manuals for the technology we use.
clang -cc1 is the frontend, clang is the driver. The driver invokes the frontend with options appropriate for your system. To see these options, run:
$ clang -### -c hello.c
Some clang command line options are driver-only options, some are frontend-only options. Frontend-only options are intended to be used only by clang developers. Users should not run clang -cc1 directly, because -cc1 options are not guaranteed to be stable.
If you want to use a frontend-only option (“a -cc1 option”), for example -ast-dump, then you need to take the clang -cc1 line generated by the driver and add the option you need. Alternatively, you can run clang -Xclang <option> ... to force the driver pass <option> to clang -cc1.
The emphasis is mine. This should give you enough guidance to get what you need done.
Related
When running the command:
clang --target=wasm32 -nostdlib -Wl, --no-entry -Wl, --export-all howold.c -o howold.wasm
I get the following errors:
clang-14: error: unsupported option '--no-entry'
clang-14: error: unsupported option '--export-all'
I installed LLVM using brew install llvm and linked it properly with brew link llvm, then ran source .zshrc.
Does macOS not support these directives or am I missing an install or command somewhere? I am new to LLVM and clang on macOS so this may be an installation problem but not entirely sure.
To pass arguments to the linker, there shouldn't be a space after -Wl,. With the extra space, you're trying to give the --no-entry option to clang itself, which isn't valid.
Try this:
clang --target=wasm32 -nostdlib -Wl,--no-entry -Wl,--export-all howold.c -o howold.wasm
I have a program written on Linux in GNU C. The program compiles with GCC. I have an install shell script,
gcc -o program program.c -Wall -pedantic -std=gnu11 -lm -fopenmp
which works greatly.
The problem is with Mac. For some reason, Mac sees gcc and instead uses clang even though GCC is installed and install.sh explicitly says gcc. clang doesn't work with omp.h The problem is that clang can't use omp.h and solutions offered http://releases.llvm.org/3.7.0/tools/clang/docs/ReleaseNotes.html#openmp-support don't work, and omp.h may not work in mac at all Enable OpenMP support in clang in Mac OS X (sierra)
I never use macs, and because of this nonsense I never plan to. However, some people using my program want to use Mac, so I have to deal with this.
I've tried various shell script modifications, but none of them work, mac insists on using clang and won't use gcc
I need to do one of two things which I don't know how to do:
1) force Mac to use gcc (which it refuses to do now)
2) get clang to use omp.h in mac (which from other answers on Stack Overflow, looks impossible)
Your second option (get clang to use omp.h) is not impossible (any more). From my answer here:
Try using Homebrew's llvm:
brew install llvm
You then have all the llvm binaries in /usr/local/opt/llvm/bin. To compile the OpenMP Hello World program, for example, type
/usr/local/opt/llvm/bin/clang -fopenmp -L/usr/local/opt/llvm/lib omp_hello.c -o hello
You might also have to set the CPPFLAGS with -I/usr/local/opt/llvm/include.
I am trying to recompile binutils and GCC as a cross-compiler for m68k architecture. I am following these instructions:
http://darkdust.net/writings/megadrive/crosscompiler
However, the process keeps failing on one part or another. I have tried with binutils 2.16.1 and gcc 3.4.6, binutils 2.15 and gcc 3.4.2 and binutils 2.15 and gcc 3.4.6.
This last attempt fails when running "make" on gcc, after making and installing binutils. It gives the following error:
gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H
-I. -I. -I../../gcc-3.4.2/gcc -I../../gcc-3.4.2/gcc/. -I../../gcc-
3.4.2/gcc/../include \
-DTARGET_MACHINE=\"m68k-coff\" \
-c ../../gcc-3.4.2/gcc/collect2.c -o collect2.o
In file included from /usr/include/fcntl.h:289:0,
from ../../gcc-3.4.2/gcc/system.h:214,
from ../../gcc-3.4.2/gcc/collect2.c:30:
In function ‘open’,
inlined from ‘collect_execute’ at ../../gcc-3.4.2/gcc/collect2.c:1535:20:
/usr/include/x86_64-linux-gnu/bits/fcntl2.h:50:4: error: call to
‘__open_missing_mode’ declared with attribute error: open with O_CREAT or
O_TMPFILE in second argument needs 3 arguments
__open_missing_mode ();
^
Makefile:1364: recipe for target 'collect2.o' failed
make[1]: *** [collect2.o] Error 1
make[1]: Leaving directory '/home/gabriel/src/gcc-build/gcc'
Makefile:23339: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2
I don't expect to fix this error, but does anyone know of a combination of binutils and gcc release that work? Should I be using a certain version of gcc to recompile gcc successfuly?
Thanks for any insight you may have on this!
EDIT:
My linux has GCC 5.4.0 so I just downloaded the 5.4.0 source to try and rebuild that for m68k cross-compiling. I now get the following error when running "make" on the gcc source:
*** Configuration m68k-unkown-coff not supported
What could be the cause of this? Is it because I need an older version of GCC? (the binutils version i'm using definately supports the m68k target). The tutorial I'm using always defines "--target=m68k-coff", should that instead be "--target=m68k-unkown-coff"?
EDIT 2:
So I tried compiling for m68k-elf but now I get this error:
checking for m68k-elf-gcc... /home/gabriel/src/gcc-build/./gcc/xgcc -B/home/gabriel/src/gcc-build/./gcc/ -B/opt/m68k/m68k-elf/bin/ -B/opt/m68k/m68k-elf/lib/ -isystem /opt/m68k/m68k-elf/include -isystem /opt/m68k/m68k-elf/sys-include
checking for suffix of object files... configure: error: in `/home/gabriel/src/gcc-build/m68k-elf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
I ran download_prerequisites before building so it should not be a problem with the MPC library. Any idea how to move on? I need assembler only so I don't mind what the format of the object files is. Thanks!
I used to do pretty much what you are doing right now.
My advice is to use crosstool-ng (http://crosstool-ng.github.io), as it does pretty much everything in an automated manner.
If you are studying m68k assembly, I used to host a modified version of gcc-explorer by Matt Godbolt (https://godbolt.org/). You can find a runnable docker image here (https://hub.docker.com/r/esantoro/acso-explorer/) and some more details here (https://znpy.wordpress.com/2017/05/08/decommisioning-acso-explorer-santoro-tk/)
Hope it helps,
znpy
you can build most versions with a current Linux. To install the prerequisites have a look at https://github.com/bebbo/amiga-gcc
unpack the gcc archive, e.g. to /opt/cross/gcc-6.5.0
create a separate build folder, e.g. /opt/cross/xcc-6.5.0 - never build inside gcc's source folder!
create the prefix folder, that's where binaries are installed to, e.g. /opt/cross/gcc65
ensure that these folders exist and are writable, then
configure from within that build folder using an absolute path for configure
cd /opt/cross/xcc-6.5.0/
/opt/cross/gcc-6.5.0/configure --target=m68k-elf --program-prefix=m68k-elf- --enable-languages=c,c++ --prefix=/opt/cross/gcc65 --disable-libssp --disable-nls --disable-multilib
make all-gcc
make install-gcc
I'm also running the compiler explorer for 68k gccs at https://franke.ms/cex/
I got a gcc compilation error:
gcc-4.9: error: unrecognized command line option '-rdynamic'
and I tested compilation with -rdynamic in some environments. While I used the same version of gcc (4.9.2), in some environments gcc worked well, but others (e.g. Homebrew gcc 4.9.2_1, cygwin 64bit) not. What makes the difference?
-rdynamic passes the flag -export-dynamic to ELF linker, on targets that support it.
Executable formats in OS X and Windows are not ELF, thus the option -rdynamic is not supported building for these operating systems.
When I run the following command from a makefile on 64-bit Red Hat Enterprise Linux 5.0 using GCC 4.2.3:
gcc -c -ansi -pedantic -O0 -fPIC -I. -I.. -Iheader_files/include "source_file.c"
I get the following error:
cc1: error: unrecognized command line option "-lang-c"
Superficially, the problem is that "-lang-c" is no longer a valid option on newer versions of GCC. However, the deeper question is: Why does GCC receive a "-lang-c" option that wasn't in the original command?
Additional background:
The current installation doesn't have any GCC "specs" files that I can find
Running "gcc -dumpspecs" produces a long list of defaults, but "-lang-c" isn't among them.
"-lang-c" does not appear to be in any environment variables that I know of that influence GCC.
Any help would be appreciated.
Regards,
Mark Biesiada
Make sure that your gcc driver program is the same version as your installed GCC.
Add the -v option to your compile command to check the versions and where the options are coming from.