When I compile with gcc -v hello.c*, the output shows a search path for #include:
$ gcc -v hello.c
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
...
clang -cc1 version 9.1.0 (clang-902.0.39.2) default target x86_64-apple-darwin17.7.0
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Library/Developer/CommandLineTools/usr/lib/clang/9.1.0/include
/Library/Developer/CommandLineTools/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
Is there a way to determine definitively which of these locations is used? For example, say that hello.c contained #include <stdio.h>. I can see manually that there are versions of stdio.h in multiple locations, presumably which can use different function construction:
$ find /usr/local/include -name "stdio.h"
/usr/local/include/c++/5.5.0/tr1/stdio.h
$ find /Library/Developer/CommandLineTools/usr/include -name "stdio.h"
/Library/Developer/CommandLineTools/usr/include/c++/v1/stdio.h
$ find /usr/include -name "stdio.h"
/usr/include/c++/4.2.1/tr1/stdio.h
/usr/include/sys/stdio.h
/usr/include/stdio.h
In Python, this would look something like:
>>> import math
>>> math.__file__
'/Users/brad/miniconda3/lib/python3.6/lib-dynload/math.cpython-36m-darwin.so'
*I'm on a Macbook, so gcc actually seems to route to clang, although it appears to be a bona fide executable rather than symlink.
From gcc man page:
-H
Print the name of each header file used, in addition to other normal activities. Each name is indented to show how deep in the #include stack it is. Precompiled header files are also printed, even if they are found to be invalid; an invalid precompiled header file is printed with ...x and a valid one with ...! .
Related
I'm trying to compile a simple C program on an M1 Mac that includes gmp.h. For whatever reason, however, it continuously says that it can't find the library. I checked to see if it exists via locate libgmp.a to which it says it is located in /opt/local/lib/libgmp.a. I also attempted to install it via brew to no avail. I really don't understand what I'm doing wrong here. I also checked the PATH environment variable to make sure this path was included, which it is.
The output of find /opt/local -type f -name "gmp.h" is /opt/local/include/gmp.h, and the output of find /opt/local -type f -name "libgmp*" is
/opt/local/libgmp.a
/opt/local/lib/libgmpxx.4.dylib
/opt/local/lib/libgmp.a
/opt/local/lib/libgmpxx.a
/opt/local/lib/libgmp.10.dylib
I compiled by linking via -L/opt/local/lib -lgmp does not fix the issue.
Command used: gcc main.c -o main.o -L/opt/local/lib -lgmp
To compile a program that relies on a header file:
#include <gmp.h>
located in a non-standard location /usr/local/include/gmp.h you need to tell the compiler where to find it by setting the directory where to find the header file:
gcc -c main.c -I/usr/local/include
Note: gpp -x c -v
To link the program, you need to tell the compiler which library to use (-l) and where to find that library (-L) which in this case /usr/local/lib/gmp.a:
gcc main.o -o main -L/usr/local/lib -lgmp
Note: gcc -print-search-dirs | grep ^libraries
If you are using a dynamic library (.so), you may also need to tell the linker where to find the library at run-time:
export LD_LIBRARY_PATH=/usr/local/lib
./main
I have a problem with #include <stdio.h> on mac Mojave 10.14.1
I have a default gcc compiler together with other gcc compilers.
DorothyeMacBook:Desktop dorothy$ which gcc
/usr/local/bin/gcc
The version is
DorothyeMacBook:Desktop dorothy$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.1.0/lto-wrapper
Target: x86_64-apple-darwin15.6.0
Configured with: ../gcc-7.1.0/configure --enable-languages=c++,fortran
Thread model: posix
gcc version 7.1.0 (GCC)
Now I am in the path :
/Users/dorothy/Desktop
I have stdio.h in the lib
DorothyeMacBook:Desktop dorothy$ find /usr -name "stdio.h"
find: /usr/sbin/authserver: Permission denied
/usr/local/include/c++/7.1.0/tr1/stdio.h
/usr/local/include/c++/4.9.2/tr1/stdio.h
/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/7.1.0/include/ssp/stdio.h
/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/include/ssp/stdio.h
/usr/local/Cellar/gcc/8.2.0/include/c++/8.2.0/tr1/stdio.h
/usr/local/Cellar/gcc/8.2.0/lib/gcc/8/gcc/x86_64-apple-darwin18.2.0/8.2.0/include/ssp/stdio.h
/usr/local/Cellar/gcc/8.2.0/lib/gcc/8/gcc/x86_64-apple-darwin18.2.0/8.2.0/include-fixed/stdio.h
However when I compile the file under the current path /Users/dorothy/Desktop Terminal will give me an error:
DorothyeMacBook:Desktop dorothy$ gcc inverse.c -o inv
inverse.c:1:10: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^~~~~~~~~
compilation terminated.
I still have a problem linking gcc with stdio.h on my mac. However, I have found an alternative way to compile the program with gcc. I typed brew install gcc in my terminal, that means a new gcc8.0.2 will be installed.(which is my case, I don't know what gcc you will get) Then I use gcc-8 instead of gcc to compile my program. In this way, the new gcc8.0.2 is invoked.
You can check the command name for gcc variants by going to /usr/local/bin All the names for gcc commands are listed there. As for me, those are
g++
g++-8
gcc
gcc-8
If you have further question, you can contact me and I will give more details.
#Jonathan Leffler is right. Apple made another big cake for us.
Since /usr/include has been moved (now it in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include after you install commandline tools), old versions of gcc build cannot find the most bottom level include files. And this is a problem. (What are there in their head) So only you are developer you use /usr/include?
This is NOT Unix-like.
Here is what happened. For gcc-4.9(gcc-4.9 and gcc-9 below are all brew gcc.), the include search paths are:
enter ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
.
/usr/local/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/usr/local/Cellar/gcc#4.9/4.9.4_1/lib/gcc/4.9/gcc/x86_64-apple-darwin17.3.0/4.9.4/include
/usr/local/Cellar/gcc#4.9/4.9.4_1/include
/usr/local/Cellar/gcc#4.9/4.9.4_1/lib/gcc/4.9/gcc/x86_64-apple-darwin17.3.0/4.9.4/include-fixed
/System/Library/Frameworks
/Library/Frameworks
End of search list. here
There is system level file stdio.h, this is why stdio.h cannot be found.
The problem in:
inverse.c:1:10: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^~~~~~~~~
compilation terminated.
is:
Refer to /usr/local/Cellar/gcc#4.9/4.9.4_1/lib/gcc/4.9/gcc/x86_64-apple-darwin17.3.0/4.9.4/include/ssp/stdio.h
#ifndef _SSP_STDIO_H
#define _SSP_STDIO_H 1
#include <ssp.h>
#include_next <stdio.h>
#include_next means include next one name stdio.h, this one is just a guider.
Give a deprecated shot. cp all files in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include to /usr/local/Cellar/gcc#4.9/4.9.4_1/lib/gcc/4.9/gcc/x86_64-apple-darwin17.3.0/4.9.4/include-fixed, gcc-4.9 will work again.
But for gcc-9 the path problem is fine. See:
#include "..." search starts here:
#include <...> search starts here:
.
/usr/local/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include # key path
/usr/local/Cellar/gcc/9.1.0/lib/gcc/9/gcc/x86_64-apple-darwin18/9.1.0/include
/usr/local/Cellar/gcc/9.1.0/lib/gcc/9/gcc/x86_64-apple-darwin18/9.1.0/include-fixed
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks
End of search list.
Actually this bug can be simply fixed by reinstall xcode commandline tools, after that gcc-4.9 will work again.
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).
This question already has answers here:
What are the GCC default include directories?
(5 answers)
Closed 8 years ago.
I'm trying to programmatically find the #include path on Linux, which as I understand it, in practice means finding what GCC considers it to be. (Is that quite true? How does Clang do it?)
According to http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html some of the components involve the CPU architecture and the GCC version; the latter in particular seems tricky; I suppose it could be obtained by running gcc --version and parsing the output (or gcc -v), but this seems inelegant at best and fragile at worst. Doing it from within one's code assuming one's program is being compiled with GCC might be another option, but it would require depending on that assumption.
What's the recommended way to do it?
The command
echo | gcc -E -Wp,-v -
will show the include path in use.
I'm not sure what you mean by the recommended way to find the include path. The standard way is as given below (for c and c++):
$ `gcc -print-prog-name=cc1` -v
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
/usr/include
End of search list.
^C
$ `gcc -print-prog-name=cc1plus` -v
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.7
/usr/include/c++/4.7/x86_64-linux-gnu
/usr/include/c++/4.7/backward
/usr/lib/gcc/x86_64-linux-gnu/4.7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
/usr/include
End of search list.
^C
see if i write in any c file like
#include "header.h"
then it will search this file in current directory
but when i write
#include <header.h>
then where it will go to find this file ?
what is defualt path for header file included in c program?
see i have installed gstreamer in /usr/local but when i am including
#include <gst/gst.h>
i am geeting fatal error: gst/gst.h: No such file or directory
How can i remove this error?
Try running gcc -v -E -. When I do, part of the output is as follows:
#include <...> search starts here:
/usr/lib/gcc/i686-linux-gnu/4.6.1/include
/usr/local/include
/usr/lib/gcc/i686-linux-gnu/4.6.1/include-fixed
/usr/include/i386-linux-gnu
/usr/include
It's not an answer to the gstreamer question, but I hope this still helps!
Pulled from here
The default paths are
/usr/local/include
/usr/include
If you use another path, you can add in your compile command with -I flag. In your case, assuming you have a /usr/local/gst/include directory, you may add -I/usr/local/gst/include and use #include <whatever_you_need.h>
The path searched depends on the implementation (and current configuration). The correct way to find the include path is to use pkg-config
pkg-config --cflags gstreamer
The default path for <> stuff is /usr/include, at least on Unix.
You can add as many default paths as you want with -I /my/new/path compiler option.
`gcc -print-prog-name=cc1` --verbose
and then CTRL+C
you can find those files in:
/usr/include