From the docs:
CPATH specifies a list of directories to be searched as if specified with -I, but after any paths given with -I options on the command line. This environment variable is used regardless of which language is being preprocessed.
On my machine, I'd like to e.g. cross-compile or, otherwise have an versioned set of alternative includes. I'd like to use those to compile other people's code.
Concretely, I have several different versions of python, and their related Python.h files.
$ python setup.py pillow
fails because the include it finds first isn't the one needed.
(/usr/local/include has an old Python.h, but I need /usr/local/include/Python2.7 to "win").
Adding /usr/local/include/Python2.7 to CPATH (or C_INCLUDE_PATH) doesn't work because it's placed later.
As far as I can see, this isn't python-specific -- surely there's a way to force GCC to have paths prior to -I / CPATH?
Its a bit hacky, but you can add it to your compiler var
Makefile syntax
CC = gcc -Ipath
Or
export CC="gcc -Ipath"
Or g++ for the CXX variable.
Related
I am attempting to compile this code:
#include <GLFW/glfw3.h>
int main() {
glfwInit();
glfwTerminate();
return 0;
}
Using this command in MSYS2 on Windows 10:
gcc -Wall runVulkan.c -o runVulkan
as well as this:
gcc -Wall -Llibs/glfw runVulkan.c -o runVulkan
libs/glfw is where I downloaded the library to.
For some reason I keep getting this:
runVulkan.c:1:10: fatal error: GLFW/glfw3.h: No such file or directory
1 | #include <GLFW/glfw3.h>
| ^~~~~~~~~~~~~~
compilation terminated.
It seems like I'm getting something very basic wrong.
I'm just getting started with C, I'm trying to import Vulkan libraries.
Run pacman -S mingw-w64-x86_64-glfw to install GLFW.
Then build using gcc -Wall runVulkan.c -o runVulkan runVulkan.c `pkg-config --cflags --libs glfw3`.
The pkg-config command prints the flags necessary to use GLFW, and the ` backticks pass its output to GCC as flags. You can run it separately and manually pass any printed flags to GCC.
Note that any -l... flags (those are included in pkg-config output) must be specified after .c or .o files, otherwise they'll have no effect.
For me pkg-config prints -I/mingw64/include -L/mingw64/lib -lglfw3.
-I fixes No such file or directory. It specifies a directory where the compiler will look for #included headers. Though it's unnecessrary when installing GLFW via pacman, since /mingw64/include is always searched by default.
-l fixes undefined reference errors, which you'd get after fixing the previous error. -lglfw3 needs a file called libglfw3.a or libglfw3.dll.a (or some other variants).
-L specifies a directory where -l should search for the .a files, though it's unnecessrary when installing GLFW via pacman, since /mingw64/lib is always searched by default.
#include are just headers, for declarations. gcc, as any compilers, needs to know where those .h should be searched.
You can specify that with -I option (or C_INCLUDE_PATH environment variable).
You'll also need -L option, this times to provide the library itself (.h does not contain the library. Just declarations that the compiler needs to know how to compile codes that use the library function's and types).
-L option tells the compiler where to search for libraries.
But here, you haven't specify any libraries (just headers. And I know that it seems logical that they go together. But strictly speaking, there is no way to guess from #include <GLFW/glfw3.h> which library that file contain headers for (that is not just theory. In practice, for example, the well known libc declarations are in many different headers)
So, you will also have to specify a -l option. In your case -lglfw.
This seems over complicated, because in your case you compile and like in a single command (goes from .c to executable directly). But that are two different operations done in one command.
Creation of an executable from .c code source is done in two stage.
Compilation itself. Creating .o from .c (many .c for big codes), so many compilation commands. Using command such as
gcc -I /path/where/to/find/headers -c mycode.c -o mycode.o
Those are not related to the library. So no -l (and therefore no -L) for that. What is compiled is your code, so just your code is needed at this stage. Plus the header files, because your code refers to unknown function and types, and the compiler needs to know, not their code, but at least declarations that they really exist, and what are the types expected and returned by the functions is the headers files.
Then, once all the .o are compiled, you need to put together all compiled code, yours (the .o) and the libraries (which are somehow a sort of .zip of .o) to create an executable. That is called linking. And is done with commands like
gcc -o myexec mycode1.o mycode2.o -L /path/where/to/search/for/libraries -lrary
(-lbla is a compact way to include /path/where/to/search/for/libraries/libbla.so or /path/where/to/search/for/libraries/libbla.a)
At this stage, you no longer need -I or anything related to headers. The code is already compiled, headers has no role left. But you need everything needed to find the compile code of the libraries.
So, tl;dr
At compilation stage (the stage that raises the error you have for now), you need -I option so that the compiler knows where to find GLFW/glfw3.h
But that alone wont avoid you the next error that will occur at linking stage. At this stage, you need -lglfw to specify that you want to use that library, and a -L option so that the compiler knows where to find a libglfw.so
I set up this toolchain on my Windows machine for my Pi (raspberry-gcc4.6.3-nosysroot.exe) and then I followed the instructions here to synchronize my sysroot.
I use a library called WiringPi in my project, and I have confirmed that it is in the synchronized sysroot:
Then I attempt to compile it:
arm-linux-gnueabihf-gcc -Wall -O -c main.c
But I get the following error:
fatal error: wiringPi.h: No such file or directory
What do I have to do to make the compiler find the header file? I thought the whole point of synchronizing the sysroot was to make this kind of thing work?
You'll have to let gcc know where to look for the include files via the -I argument. In the case above, -IC:\SysGCC\Raspberry\...\usr\local. You may have to add more than one include path, depending on where the required files are scattered. You can also try to set gcc's environment variable(s).
Finding out the correct include path can be a little tedious (see above: should it be local\ or local\include\?). Maybe you can find the environment setting for all default include paths on your Pi and just copy it over to your Windows machine.
Edit: Think I got it: echo | gcc -v -E -
For whatever reason, the third party drivers I'm using need to have -I/usr/include added as a compiler flag in the Makefile or else make fails because it can't find certain header files.
I don't want to have to edit the supplied Makefile, but rather pass in the -I/usr/include to ./configure in my own bash script which builds several other drivers..
I've tried both of the following with ./configure
--includedir=DIR C header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
DIR replaced with /usr/include
Both times the build fails, but if I add -I/usr/include to EXTRA_CFLAGS in the makefile, then the make runs successfully.
Is it possible to supply make or configure with the include directory so I don't have to edit the third party makefile? Or am I just missing something somewhere?
If it's a standard autoconf package then the user (you) owns the CFLAGS, CXXFLAGS, and CPPFLAGS (the CPP here stands for C preprocessor, not C++) variables so you can modify them as you like. For example, either of these should do what you want:
./configure CPPFLAGS='-I/usr/include'
or:
make CPPFLAGS='-I/usr/include'
I don't get it. I usually install third party software into /usr/local so libraries are installed into /usr/local/lib and never had problems linking to these libraries. But now it suddenly no longer works:
$ gcc -lkaytils -o test test.c
/usr/bin/ld.gold.real: error: cannot find -lkaytils
/usr/bin/ld.gold.real: /tmp/ccXwCkYk.o: in function main:test.c(.text+0x15):
error: undefined reference to 'strCreate'
collect2: ld returned 1 exit status
When I add the parameter -L/usr/local/lib than it works but I never had to use this before. Header files in /usr/local/include are found without adding -I/usr/local/include.
I'm using Debian GNU/Linux 6 (Squeeze) which has an entry for /usr/local/lib in /etc/ld.so.conf.d/libc.conf by default and the ldconfig cache knows the library I'm trying to use:
k#vincent:~$ ldconfig -p | grep kaytils
libkaytils.so.0 (libc6,x86-64) => /usr/local/lib/libkaytils.so.0
libkaytils.so (libc6,x86-64) => /usr/local/lib/libkaytils.so
So what the heck is going on here? Where can I check which library paths are searched by gcc by default? Maybe something is wrong there.
gcc -print-search-dirs will tell you what path the compiler checks. /usr/local/lib is simply not among them, so your compile time linker (in this case the new gold ld from binutils) doesn't find the library while the dynamic one (ld-linux.so which reads the cache written by ldconfig) does. Presumably the builds you've done previously added -L/usr/local/lib as necessary in their makefiles (usually done by a ./configure script), or you installed binaries.
This is probably an issue of environment variables - you have something set that's including /usr/local/include but not /usr/local/lib
From the GCC mapage on environment variables
CPATH specifies a list of directories to be searched as if speci‐
fied with -I, but after any paths given with -I options on the com‐
mand line. This environment variable is used regardless of which
language is being preprocessed.
and
The value of LIBRARY_PATH is a colon-separated list of directories,
much like PATH. When configured as a native compiler, GCC tries
the directories thus specified when searching for special linker
files, if it can’t find them using GCC_EXEC_PREFIX. Linking using
GCC also uses these directories when searching for ordinary
libraries for the -l option (but directories specified with -L come
first).
try "printenv" to see what you have set
I'm running OSX 10.6.6. I have installed Apples GCC- version 4.2.1. I'm writing myself a nice little library- things for debugging, data storage algorithms, and the like. I've stored all the headers and .c files in a nice little folder called 'mylib' in my C folder. I'd like to add that folder to the GCC search path, so that I can type, say,
/* ... */
#include <mylib/debug.h>
/* ... */
and have it work perfectly. How can I either add /Users/Henry/coding_stuff/c/include/mylib to the GCC search path, or have a reference to the folder in /usr/include? I'd like to not have to replace /usr/include/mylib with the one in my C folder every time I make a trivial change. So, how can it be done?
A symbolic link will work:
sudo ln -s /Users/Henry/coding_stuff/c/include/mylib /usr/include/mylib
A more traditional way to solve this problem is to use the compiler's -I flag to add your search path:
gcc -I /Users/Henry/coding_stuff/c/include/mylib -c -o example.o example.c
Add to your .bashrc:
export INCLUDE_PATH=/Users/Henry/coding_stuff/c/include/mylib
You need to set the environment variable LD_LIBRARY_PATH to equal the path. Most likely in your .bashrc.
export LD_LIBRARY_PATH=/path/to/libs
Sorry this should actually be LIBRARY_PATH for the build; LD_LIBRARY_PATH is for runtime library linking.
export LIBRARY_PATH=/path/to/libs
I'm using Ubuntu14.04 and gcc.
gcc adds C_INCLUDE_PATH to the list of search directories.
You can use -v option to see where gcc actually searchs.
(INCLUDE_PATH does not work for me.)
So, you can add the following to .bashrc:
export C_INCLUDE_PATH=/Users/Henry/coding_stuff/c/include/mylib
I found the official documentation: https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html