I am trying to get some code that I acquired from a repository to work on my system.
In one of the C files, it contains an absolute path to a header:
#include "/home/user/.rvm/rubies/ruby-1.9.2-p290/include/ruby-1.9.1/x86_64-linux/ruby/config.h"
Because this file and directory does not exist on my system, compiling the source code fails.
I assume if I change this to point at my personal location of config.h, it will succeed but then fail on others' systems.
Is there a way to point at some symbolic link that the system will then use the proper location for such a file? What is the best way to approach this situation?
Change it to #include "ruby/config.h", and then add -I/home/user/.rvm/rubies/ruby-1.9.2-p290/include/ruby-1.9.1/x86_64-linux/ (or whatever your location is) to your compiler options. This tells the preprocessor to add that directory to the list of directories to search when looking for #includes.
To solve the portability you can then change whatever generates the makefile to take this path as an option/argument, or you can just put it in a variable at the top of the makefile and ask people to change it:
RUBY_LOCATION = /home/user/.rvm/rubies/ruby-1.9.2-p290/include/ruby-1.9.1/x86_64-linux/
CFLAGS = -Wall -I${RUBY_LOCATION}
Related
I am currently taking a class on C and I am baffled by gcc options a lot of the time, because the videos/documentation on the options are sparse and those that eixst are hard to understand(for idiots/non-technical majors like myself). Please consider the following scenario:
Lets say I have a header file, myHeader.h and main.c which would like to include myHeader.h. Assume they are in the same directory.
In main.c, I could write #include "myHeader.h". However, according to my professor the "" is permitted because gcc will check in the current directory for anything in the "". However, where I am lost is when it comes to how I could add myHeader.h to the gcc header file search path such that #include <myHeader.h> would work. I am wondering what gcc commands would work, and why they work in specific. I would love any references(that aren't super nerdy) to better understand this.
So far, I researched on stackoverflow and on google, and it said something about -Idir gcc command, where dir is the directory you would like to add to the header file search path, but I am confused as to why this works or how to actually implement it. Since the "path" to myHeader.h is CStuff/workspace/myHeader.h I attempted to do gcc -I/CStuff/workspace/myHeader.h but this didn't really work out. I really thought it would take that directory and add it to the header file search path, but it just gave me an error.
I am a very confused business major so please take it easy on me! I really would love a dumbed-down explanation or a reference to a source that is more "basic" and has more than 1-2 sentences of explanation(if possible).
However, where I am lost is when it comes to how I could add myHeader.h to the gcc header file search path such that #include <myHeader.h> would work.
If you want to add search path directory for system headers, there is -isystem <path>. For ordinary headers — which your header very likely is — there is -I <path>. This supports relative and absolute path formats.
To see which search paths GCC is using, add -v to the options:
> gcc main.c -v ...
...
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/9/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
...
There are more special options, see Directory-Options in the GCC documentation, if it comes to search order, for instance.
To see the outcome of including, i.e. the C-preprosessed file, use -save-temps and have a look at the preprocessed file *.i for C, *.ii for C++, *.s for assembly.
To also see built-in and explicit #define's values in preprocessed code, also add -H -g3.
In main.c, I could write #include "myHeader.h". However, according to my professor the "" is permitted because gcc will check in the current directory for anything in the "". However, where I am lost is when it comes to how I could add myHeader.h to the gcc header file search path such that #include <myHeader.h> would work.
As a preliminary matter, you are already lost when you conceive the idea that you should want to use that form for the private headers associated with your program. The <header.h> form is conventionally and best reserved for use with system headers. That is, exactly those that do not accompany the code being compiled.
That does not moot the question, however. Sometimes one might want to amend the header search path to help the compiler find headers distributed with the source code and referenced via the "header.h" form, too.
I am wondering what gcc commands would work, and why they work in specific. I would love any references(that aren't super nerdy) to better understand this.
You will not earn friends or respect here by eschewing technical references, nor by casting aspersions on those who do read such references. Technical documents can be hard reading at first, but reading and understanding them is a skill that you will need to cultivate if you want to enjoy success as a programmer.
So far, I researched on stackoverflow and on google, and it said
something about -Idir gcc command, where dir is the directory you
would like to add to the header file search path,
Good start.
but I am confused as
to why this works or how to actually implement it. Since the "path" to
myHeader.h is CStuff/workspace/myHeader.h I attempted to do gcc
-I/CStuff/workspace/myHeader.h but [...] it just gave me an error.
It is important to pay attention to details. You yourself wrote:
where dir is the directory you would like to add to the header file search path
(emphasis added). If /CStuff/workspace/myHeader.h is the header you want gcc to find, then that path is not the path of a directory. The directory is /CStuff/workspace, so -I/CStuff/workspace is a viable option.
Alternatively, for gcc runs in which the working directory is also /CStuff/workspace, you can refer to it by the name . (that is, use -I.). It is a general feature of Unix and Windows paths, not specific to gcc, that the . represents the current working directory.
I've been trying to work without an IDE. Now I'm setting up a project that I had done
on stm32cubeIDE. I got to the point where I'm adding headers and such to the main.c file. In the IDE I was able to tell the IDE where to look for headers, like the driver folder or w/e I called it. Without IDE, I had to go and change the path in the #include statement such that
#include "cooldriver.h"
became
#include "driver/cooldriver.h"
Then,I also have to change cooldriver.c's path to point to the right path.
Is there a way to simplify this so I don't have to go through and change all the #includes and just keep what I had.
I'm working in linux env and using arm-none-eabi-gcc.
The path i have is like,
main.c
Makefile
drivers
Inc
driver1.h
driver2.h
Src
driver1.c
driver2.c
TLTR: I want to tell compiler where to look for header files without an ide and without rewriting all the include statements.
Thanks.
TLTR: I want to tell compiler where to look for header files without an ide and without rewriting all the include statements.
Among their many available command-line options, compilers accept some that tell them about paths to search for headers and external libraries. On UNIX-heritage systems, the traditional one for paths that #include should consider is -I. Your compiler's documentation will provide more detail.
The traditional approach would be to set one or more variables in your makefile to contain the wanted command-line flags, and to expand those variables where appropriate in your make recipes. Sticking with convention, I would use variable CPPFLAGS for -I and other flags directed toward the C preprocessor.
I know it is possible to specify #include filepaths either relative to the directory the file is located in, as an absolute file path, or relative to any of the directories in the $PATH system variable. Is there a way to instead specify it relative to the user's current directory when the program is compiled? Let's say I have the following file structure:
|--dir_a/
| |--a.c
| |--a.h
|--dir_b/
| |--b.c
| |--b.h
|--makefile
Now let's say I want to #include the file dir_a/a.h from dir_b/b.h. Using the location of dir_b/b.h, this can be written like this:
#include ../dir_a/a.h
However, this approach has a major flaw in my opinion since it hardcodes the locations of files relative to each other, meaning that relocating a file would require updating the file path everywhere that file was included from.
Using absolute file paths would avoid this problem, but would instead hardcode the location of the project within the filesystem, which seems like bad practice.
Finally, using the <> tags to specify the file path isn't feasible either since I can't assume the project will be listed in the $PATH variable.
So what I want to do is to be able to specify the paths relative to where the user compiles from (or even better, from the location of the makefile). In the above example, this would let me use the following statement to #include dir_a/a.h from dir_b/b.h:
#include dir_a/a.h
This I think would be the ideal solution. It would make the #include statements more consistent and easier to follow, as well as avoid the drawbacks I listed above. Is it possible to do this in any way, eg. with a compiler flag or something? I'm using gcc as my compiler.
If you consistently use <> includes, then the -I options in the makefile should be enough. The directory layout shows only one makefile, in the parent directory. That could use
-Idir_a -Idir_b
in the compiler options, and the .c files could just do
#include <a.h>
#include <b.h>
One of the problems with quoted includes is that their behavior with other compilers may differ, as noted in What is the difference between #include <filename> and #include “filename”? (the standard was not explicit enough). Using a gcc extension probably does not improve that situation.
I managed to solve my problem.
The first part of the solution involves specifying the -iquote flag in gcc when compiling. From man gcc:
-iquotedir
Add the directory dir to the head of the list of directories to be searched for header files only for the case of #include "file"; they are not searched for #include <file>, otherwise just like -I.
The second part of the puzzle was how to get the path to the makefile within the makefile itself. This answer worked for me. I'm pasting the solution here for convenience:
ROOT_DIR = $(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))
edit: While this approach works, this answer is more cross-compiler friendly, so I'm personally going to use that.
Yes. Any include file, which is not directly in your include path specified in your project linker settings, should have all subfolders up to it specified, like:
#include "first/second/third/folder/library.h"
Vim is pretty smart when it comes to C, so if one inserts a bogus header file such as #include <stdioo.h>, it complains by bringing up a location list with the following error:
foo.c:1|20| fatal error: stdioo.h: No such file or directory
|| compilation terminated.
Which is great, but for whatever reason, I get the same error when including the <mpi.h> header file. I know this is a vim problem b/c I can compile and execute the program with mpicc and mpiexec, respectively. Besides it being extremely irritating having it pop up every time I save the file, all syntax errors are ignored when this happens.
Is there any way to instruct vim to ignore this header file, or at least all the header files?
WHERE on your filesystem is the <mpi.h> file located?
Often it's one level down, such as /usr/include/mpi/mpi.h and would require <mpi/mpi.h> to access it.
You may need to add another directory path to the -I option list of your compiler, or add the directory path to VIM's path option variable
:help 'path
Will get you started on the VIM side, you'll need to look up how to add options to your current setup, no idea if you're using cmake, make, visual something, netclipse or whatever.
But a simple 'locate mpi.h' would be the place to start, since you know it's there.
You said "pop-up" ... are you using syntastic or such? Again, finding the proper path would help there too. Evidently mpicc knows the proper path to the include files, you just need to tell VIM. (via the 'path' option)
I am still fairly new to programming with C and I am working on a program where I want to control the power to various ports on a hub I have. That is, however, not the issue I am having right now.
I found a program online that does what I want I am trying to compile it. However it uses #include<lsusb.h>. lsusb is located in a totally different folder than the file I am wanting to run (and not in a sub folder) and when I try to compile it, I, logically enough, get the error that the file lsusb.h is not found.
How can I link to this file so that it can be found?
This is more of a GCC toolchain question than a C question (although most C compilers do use the same Unixy flags).
The braces around the include file (<>) indicate you want the compiler to search its standard search path for the include file. So you can get access to that new include file either by putting it into a directory on your standard include file search path yourself, or by adding its directory to the file search path. With GCC you do the latter by giving gcc the flag -I"directoryname" where "directoryname" is the full file path to where you are keeping that new include file of yours.
Once your compiler finds it, your linker may have the exact same problem with the library file itself ("liblsusb.a"?). You fix that the same way. The flag GCC's linker will want is -L instead of -I.
See the "-I" parameter in the gcc man page. It allows you specify a directory in which to find a header file. See also -l and -L.
Or try #include "../../path_to_the_file/lsusb.h"