Getting clang error:
fatal error: 'stdint.h' file not found
I have extracted the exact compilation command from makefile which is throwing the above error:
clang -MD -MP -std=c99 -include sys/cdefs.h -Wall -O2 -target armv6k-none-eabi -mfloat-abi=soft -m32 -emit-llvm -ffreestanding -nostdlib -nostdinc -Wno-c11-extensions -I/Path/To/Project/include -I/Path/To/Project/genconfig -c folder1/abc.c -o folder1/abc.bc
somefile.h:50: fatal error: 'stdint.h' file not found
# include <stdint.h>
^
The somefile.h is just a normal file inside the project.
Would like to know why the above clang command is generating the mentioned compilation error.
In addition to the above main question, Anyone please explain what is this .bc file - see at the end of command? In general few words about this llvm-clang concept. I would Highly appreciate it.
I have to compile without using standard headers. So -nostdinc option should be present in the command. Actually I am compiling some kernel (small version) which is not suppose to use standard includes or libs.
My system:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.4 LTS
Release: 16.04
Codename: xenial
Related
I am unsure of what could be causing this as I have tried recompiling libcurl and using pre-compiled binaries.
My compiler command
x86_64-w64-mingw32-gcc -Wall -Lwin-lib -Iwin-lib -I./ -D WIN32 -D CURL_STATICLIB -mwindows ... -o win-export/SLM.exe -lm -lraylib -ltmx -lxml2 -lzlibstatic -lcurl
There aren't any compiler errors or linker errors. Is this a problem with my compiler? Or one the other libraries I am using?
I am getting build errors when I build MacPorts on my iMac running the latest Big Sur beta. Yeah I know, it's beta, but I think my question is still relevant. Please see below for the full error message (first error of many). Thanks for any help!
clang -MM -MP -DHAVE_CONFIG_H -I/Users/rcook/current_projects/macports-base/src -I/Users/rcook/current_projects/macports-base/src -I. -I/Users/rcook/current_projects/macports-base/vendor/vendor-destroot/opt/local/libexec/macports/include -I./../compat access.c > access.d
clang -g -O2 -std=c99 -Wextra -Wall -fPIC -arch arm64 -arch x86_64 -DHAVE_CONFIG_H -I/Users/rcook/current_projects/macports-base/src -I/Users/rcook/current_projects/macports-base/src -I. -I/Users/rcook/current_projects/macports-base/vendor/vendor-destroot/opt/local/libexec/macports/include -I./../compat -c -o access.o access.c
In file included from access.c:36:
In file included from ./darwintrace.h:40:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:55:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_types.h:27:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:32:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:807:2: error: Unsupported architecture
#error Unsupported architecture
I'm trying to compile zbar-0.10 to be statically linked to the MinGW dependencies, so it doesn't require libgcc_s_dw2-1.dll, libwinpthread-1.dll, and libstdc++-6.dll.
Following the accepted answer from MinGW .exe requires a few gcc dll's regardless of the code?, I tried adding -static -static-libgcc -static-libstdc++ to my ./configure script parameters:
./configure -static-libgcc -static-libstdc++ -static -lpthread --without-qt --without-gtk --without-python --without-imagemagick
But I got this error:
configure: error: unrecognized option: -static-libgcc
What are the correct parameters to pass to the configure script so the MinGW dependencies are statically linked to ZBar?
The option -static is enough for what you want achieve when you use MinGW toolchain.
Update: I got it working, the problem has something to do with the fact that I was running it through emacs. I ran the makefile from the command line instead, and pkg-config ran. After adding the path to guile-2.0.pc with export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig everything compiled and ran OK. Still won't compile through emacs but I don't want to deal with that.
I am trying to compile a C program but received a "pkg-config: command not found" error, but am pretty sure pkg-config is installed.
Below is the MAKEFILE
# Use GCC, if you have it installed.
CC=gcc
# Tell the C compiler where to find <libguile.h>
CFLAGS=`pkg-config --cflags guile-2.0`
# Tell the linker what libraries to use and where to find them.
LIBS=`pkg-config --libs guile-2.0`
simple-guile: simple-guile.o
${CC} simple-guile.o ${LIBS} -o simple-guile
simple-guile.o: test.c
${CC} -c ${CFLAGS} test.c
Below is the error message (re: second error, I think if I can resolve this issue the libguile.h file will be found)
make
gcc -c `pkg-config --cflags guile-2.0` test.c
/bin/sh: pkg-config: command not found
test.c:2:11: fatal error: 'libguile.h' file not found
#include <libguile.h>
^
1 error generated.
make: *** [simple-guile.o] Error 1
I installed pkg-config by
brew install pkg-config
Installation appears successful?...
Jeffs-iMac:~ Jeff$ which pkg-config
/opt/local/bin/pkg-config
If it's relevant, this should be the same directory in which guile is located:
Jeffs-iMac:~ Jeff$ which guile
/opt/local/bin/guile
Am using OS X 10.11.3
I tried uninstalling and reinstalling pkg-config per: Can't install rmagick, pkg-config: command not found
I'm a novice programmer, any help would be greatly appreciated.
I am running Ubuntu 12.04 and I'm currently working on a project involving C, OpenGL, a teapot and input methods.
The problem started when I decided to have arrow keys as input. I checked to see the key codes for arrow keys but all of the arrows return 0. I looked up how to get this to work and I found conio.h. Unfortunately, it is an old DOS header that is not available for Linux. Then I found a substitute called ncurses.
After installing the necessary libraries, by following the build instructions closely, I #included curses.h in my main.c source. When I first tried to compile using gcc, I got the following errors:
main.o:main.c:function _Key: error: undefined reference to 'stdscr'
main.o:main.c:function _Key: error: undefined reference to 'wgetch'
main.o:main.c:function _Key: error: undefined reference to 'stdscr'
main.o:main.c:function _Key: error: undefined reference to 'wgetch'
I found a fix by adding -lncurses to the makefile like so:
SOURCES=main.c
main: main.o
gcc -lm -lGL -lGLU -lglut -lncurses main.o -o main
main.o: main.c
gcc -lm -lGL -lGLU -lglut -c main.c
But I was greeted by another error:
/usr/bin/ld: error: cannot find -lncurses
As well as the previous errors.
I have spent the last 2 days searching both the Ubuntu forums and StackOverFlow. Any help would be appreciated.
P.S. I don't know if this is important but when I try to run /usr/bin/ld I get this error:
ld: fatal error: no input files
For anyone with the same problem I had: I was missing the 32 bit libraries; I was compiling 32 bit on a 64 bit server which was missing the lib32ncurses5-dev package.
On Ubuntu I simply ran:
sudo apt-get install lib32ncurses5-dev
First off, you should put the libraries after the object file when linking. And not have them at all in the compilation of of the source file.
After that, if ncurses is not installed in a standard search folder you need to point out to the linker where it is, this is done with the -L command line option:
gcc main.o -o main -L/location/of/ncurses -lm -lGL -lGLU -lglut -lncurses
Try installing the ncurses-static package too, if you have only the ncurses-devel package installed in your Ubuntu OS.
If that solves your problem, plus if you add #Joachim's compiling instructions, you are off to a great start.
gcc main.o -o main -L/location/of/ncurses -lm -lGL -lGLU -lglut -lncurses
The linker can't find your shared library in it's search path. If you add the directory where your shared lib is to the LD_LIBRARY_PATH environment variable the linker should find it and be able to link against it. In that case you could omit the -L option to gcc:
gcc main.o -o main -lm -lGL -lGLU -lglut -lncurses
And it should compile fine.
EDIT:
Good to know that apt-get install libncurses5-dev fixes your problem.
FYI.
The LD_LIBRARY_PATH environment variable contains a colon separated list of paths that the linker uses to resolve library dependencies at run time. These paths will be given priority over the standard library paths /lib and /usr/lib. The standard paths will still be searched, but only after the list of paths in LD_LIBRARY_PATH has been exhausted.
The best way to use LD_LIBRARY_PATH is to set it on the command line or script immediately before executing the program. This way you can keep the new LD_LIBRARY_PATH isolated from the rest of your system i.e. local to the current running running instance of shell.
$ export LD_LIBRARY_PATH="/path/to/libncurses/library/directory/:$LD_LIBRARY_PATH"
$ gcc main.o -o main -lm -lGL -lGLU -lglut -lncurses