Compiling a C prog winth unix syle header files in windows - c

well i have a few Cpp source and header files, and the header files have include statements in the form,
#include<include/config.h>
#include<include/controls.h>
the thing is im using gcc on windows and it says no such file or directory as the windows style paths has '/' and not '\' ,
so i changed the path to include\config.h but again, the problem is config.h has many header files included in it with the similar unix path style, and its not feasible to change the paths in all the header files cos its a library and there are 100s of such headers, is there any way to compile this using GCC (minGW) ??
Thanks :)
this may sound like a silly problem, sorry if it is!!..

I don't think the direction of the / is the problem here. Windows should convert between the two for you when calling its API precisely for the purposes of (some) unix compatibility.
I think the problem is the include path. Try compiling your program with
gcc -o output.exe -I"c:\path\to\directory\above\include" file.c
So that in the directory you specify with the include flag, there is a subdirectory "include" containing your headers. This assumes all your paths in your other headers are relative to this.

config.h and controls.h are not standard header files. Try this instead:
#include "include/config.h"
#include "include/controls.h"
Even better would be to use the command line to specify the include directory and use
#include "config.h"
#include "controls.h"
Probably mingw uses the same option as all other c compilers: (compiler name) -I(directory name)...
As others have stated, / vs. \ is a non-issue. Even Microsoft compilers and utilities accept / everywhere. The use of \ is a historical mistake, perpetrated needlessly.

A good discussion of your issue can be seen here:
How to generate a OS independent path in c++

Don't change forward slash / to back-slash \ - you are making the compiler to interpret the next character as a special character \c. GCC has no problem dealing with UNIX-style paths on Windows. The problem is probably the lack of -I directive to the compiler - something like -I. to search for files in current and sub-directories.

Related

How do I set include paths when not using an IDE so it isn't cumbersome

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.

Installing a C header on Linux/POSIX systems

I have a header foo.h with functions bar(), baz(), qux(). Where would I copy it/what would I have to do it so that I can include it in C programs like other systemwide headers, like stdio.h, unistd.h etc?
From the GCC documentation (I am assuming you are using GCC since you included the Linux tag):
2.3 Search Path
GCC looks in several different places for headers. On a normal Unix system, if you do not instruct it otherwise, it will look for headers requested with #include in:
/usr/local/include
libdir/gcc/target/version/include
/usr/target/include
/usr/include
[...] In the above, target is the canonical name of the system GCC was configured to compile code for; often but not always the same as the canonical name of the system it runs on. version is the version of GCC in use.
So that mostly answers your question. But really, you probably shouldn't be putting non-system headers in places like /usr/include. Most of the time, it's best to keep the headers for your program in the include sub-directory for the project. Then tell GCC how to find those files like this:
You can add to this list with the -Idir command line option. All the directories named by -I are searched, in left-to-right order, before the default directories. The only exception is when dir is already searched by default. In this case, the option is ignored and the search order for system directories remains unchanged.
[...]
Also keep in mind the differences between #include "file.h" and #include <file.h>
GCC looks for headers requested with #include "file" first in the directory containing the current file, then in the directories as specified by -iquote options, then in the same places it would have looked for a header requested with angle brackets. For example, if /usr/include/sys/stat.h contains #include "types.h", GCC looks for types.h first in /usr/include/sys, then in its usual search path.
[...]

How can I print headers hierarchy? [duplicate]

How can I tell where g++ was able to find an include file? Basically if I
#include <foo.h>
g++ will scan the search path, using any include options to add or alter the path. But, at the end of days, is there a way I can tell the absolute path of foo.h that g++ chose to compile? Especially relevant if there is more than one foo.h in the myriad of search paths.
Short of a way of accomplishing that... is there a way to get g++ to tell me what its final search path is after including defaults and all include options?
g++ -H ...
will also print the full path of include files in a format which shows which header includes which
This will give make dependencies which list absolute paths of include files:
gcc -M showtime.c
If you don't want the system includes (i.e. #include <something.h>) then use:
gcc -MM showtime.c
Sure use
g++ -E -dI ... (whatever the original command arguments were)
If your build process is very complicated...
constexpr static auto iWillBreak =
#include "where/the/heck/is/this/file.h"
This will (almost certainly) cause a compilation error near the top of the file in question. That should show you a compiler error with the path the compiler sees.
Obviously this is worse than the other answers, but sometimes this kind of hack is useful.
If you use -MM or one of the related options (-M, etc), you get just the list of headers that are included without having all the other preprocessor output (which you seem to get with the suggested g++ -E -dI solution).
For MSVC you can use the /showInclude option, which will display the files that are included.
(This was stated in a comment of Michael Burr on this answer but I wanted to make it more visible and therefore added it as a separate answer.)
Usability note: The compiler will emit this information to the standard error output which seems to be suppressed by default when using the windows command prompt. Use 2>&1 to redirect stderr to stdout to see it nonetheless.

New .h file in /usr/include linux

I developed small c application in linux. For this application i placed .h file in
linux standard path (/usr/include). Again i am compiling the same program
Output:
FATA ERROR : xyz.h(my own header file) not found
Do i need to update any variable in gcc or way to solve this problem
Thank You
Place the header file in the same directory as your .c file and use -I. when compiling
gcc -I. main.c -o myprog
You shouldn't place your header files in /usr/include that is meant for the system headers.
Note: you don't actually need the -I. because the current directory is searched by default, nevertheless, it doesn't hurt to add it.
Files specified by include directives are meant to be located in one of the search paths of the complier which are specified with the -I option in many cases (at least for gcc, is it the same for other compilers?). The search paths are verified in the order of definition in the command line.
There are 2 kinds of include directives:
double quoted ones (#include "xyz.h")
angle bracket ones (#include <xyz.h>)
IIRC, the default and first search path for the former is the working directory. For the later, it's compiler dependant, but it's usually /usr/include/.
Depending of the include directive you used, you should pick the right location for your file. Or better, put your file in a good location (say the same place as the including file), and add a search path to your gcc command.
You should separate your header .h files, from system and repository built headers so you don't break anything.
I would recommend making a folder in your home directory called include and just adding it to your path, that way you never have to worry about it again and no need for the -I/flag

How to link a non-standard header file into a C compiler

I'm trying to use a non-standard header file (http://ndevilla.free.fr/gnuplot). Its used in lots of codes in various different places on my computer. Currently I have to put the header file and the object file in every folder which its needed with the preprocessor directive:
#include "gnuplot_i.h"
In the file. Is there a way by which I can put the header file in one place so I can reference it like other standard header file. Cheers.
Compile with -I<directory>
E.g.
compile with -I/usr/local/gnuplot/inc.
Also it might be worth your reading up on include paths and the difference between:
#include <include_file.h>
and
#include "include_file.h"
Linking in an object file needs to be done explicitly the same way as a C file, which means (I believe) that you need a full path. However if you archive it into a proper library then you can use -l<library name> and -L<library path> instead. E.g.
gcc -I/usr/local/gnuplot/inc -L/usr/local/gnuplot/lib -lgnuplot -o my_prog my_prog.c
Most compilers have a flag -I that lets you add a directory of your choosing to the search path for include files.

Resources