How to include headers located in project root compiling with GCC C++ compiler?
I want to tell GCC compiler to search for some header files in project root.
I do NOT want to make changes in code and use relative paths in #include directives - e.g. #include "../../myheader.h"
I compile source code I do not own and I do not want to maintain own version.
I do NOT want to specify absolute include path e.g. g++ -c -IC:\root_project_folder .. for obvious reasons.
I have tried: g++ -c -I .., g++ -c -I/ .. and g++ -c -I"/" .. but it does not work.
Please advise.
root_project_folder
|--myheader.h
|--src_folder
|-prog.cpp
The symbol for the current directory is ..
You're looking for -I.
Related
I am trying to compile using gfortran using the following:
$ gfortran -I/usr/local/include -O3 -Wall -Wno-uninitialized -fbounds-check -g alignparts_lmbfgs.f90 /home/vincent/test/lmbfgs/Lbfgsb.3.0/lbfgsb.f /home/vincent/test/lmbfgs/Lbfgsb.3.0/linpack.f /home/vincent/test/lmbfgs/Lbfgsb.3.0/blas.f /home/vincent/test/lmbfgs/Lbfgsb.3.0/timer.f /home/vincent/test/lmbfgs/minimal_libraries/imlib2010.a /home/vincent/test/lmbfgs/minimal_libraries/genlib.a -o alignparts_lmbfgs.exe -lfftw3 -lm
but it gave me the error
alignparts_lmbfgs.f90:105: Error: Can't open included file '/usr/include/fftw3.f'
even though I specified the -I opitions where the fftw3.f resides.
What am I doing wrong? I don't have root privileges so I can't just move the files from /usr/local/include to /usr/inlcude
I am a noob in compiling. I am only compiling because this is the only way I am getting the executable. Please be as noob-proof as possible when explaining. Thank you so much!
The compiler reports:
alignparts_lmbfgs.f90:105: Error: Can't open included file '/usr/include/fftw3.f'
This means that your source file alignparts_lmbfgs.f90 contains
a line #105 like:
INCLUDE '/usr/include/fftw3.f'
which tells the compiler to copy the file /usr/include/fftw3.f in place
of that line #105. But there is no such file.
You have passed the compiler option -I/usr/local/include which
tells the compiler to search for included files in /usr/local/include,
and you say:
I specified the -I options where the fftw3.f resides.
So probably there is such a file as /usr/local/include/fftw3.f?
In that case, can change:
INCLUDE '/usr/include/fftw3.f'
to:
INCLUDE '/usr/local/include/fftw3.f'
However, if you do that, then the compiler option:
-I/usr/local/include
is pointless, because /usr/local/include/fftw3.f is an absolute filename:
it either exists or it doesn't.
If you want the program to be compilable independently of the absolute location
of fftw3.f - which is emphatically the best practice - then replace line #105 with:
INCLUDE 'fftw3.f'
Then, if fftw3.f is in fact located in /usr/local/include, you can compile
the program with the option -I/usr/local/include, and in general if the file
is located in directory /look/here/for/headers, you can compile the program
with the option -I/look/here/for/headers.
I have made some header files and placed them in the same folder as the main program, but the compilation command gcc -ansi -Wall *.c cannot find those files. Do I have to include the full directory path of the header files or am I doing something else wrong?
First of all you have to include the header files into the relevant C-files if you haven't already done so as such:
#include "path/to/file.h"
You also have to tell the compiler to compile the .h-files so if your .h-files are in the same foder as you .c-files and you want to include all the present .h-files your compiler command would look like this:
gcc -ansi -Wall *.h *.c
I have an issue regarding the linking of a shared library with a non-standard naming convention under several directories. I need the generated executable to search for the shared library within the executables current location, but cannot find a command line parameter to force this behavior.
To demonstrate this behavior all that is required is a shared library that is under a directory.
gcc -shared mylib.c -o some/dir/mylib.so
gcc main.c -o main -Lsome/dir -l:mylib.so
The executable main gives the following ldd output:
ldd main
some/dir/mylib.so (0xf76e2000)
The output that I require is:
ldd main
mylib.so => some/dir/mylib.so (0xf7700000)
This output can be created if the library is named conventionally as libmylib.so rather than mylib.so like so:
mv some/dir/mylib.so some/dir/libmylib.so
gcc main.c -o main -Lsome/dir -lmylib
This also drops the path some/dir in the ldd listing as required.
I have investigated the use of rpath, and command line options for both the ld and gcc but I am unable to find a satisfactory solution. The strict requirements of a non-standard name and directory structure cannot be changed easily in this case.
My question is how can I force the dependency of the library to be relative to the current directory rather than absolute as in the second ldd through gcc command line options.
Thank you for your time, I hope I have explained the problem reasonably.
Jon.
Try to add soname in your shared library:
$ gcc -shared mylib.c -o some/dir/mylib.so -Wl,-soname=mylib.so
$ gcc main.c -o main -Lsome/dir -l:mylib.so
$ LD_LIBRARY_PATH=some/dir:$LD_LIBRARY_PATH ldd main
mylib.so => some/dir/mylib.so (0x00007fa7a4fd6000)
There's a magic variable you can pass to rpath to do this: $ORIGIN. See man ld.so for details.
I think in your case, the command should look like this (untested):
gcc main.c -o main -Lsome/dir -lmylib -Wl,-rpath,'$ORIGIN/some/path'
Note that you mustn't let the shell expand $ORIGIN as a shell variable.
BTW, this was the first Google hit for "rpath relative".
I have written a makefile like this:
HEADER = -I./cygdrive/c/cpros/kajj/source4
LIBB = -L./cygdrive/c/cpros/kajj/source1 -L./cygdrive/c/cpros/kajj/source2
LIBRA = -larith -ldekk
target : game.o
gcc $(HEADER) $(LIBB) $< -o $# $(LIBRA)
game.o : game.c
gcc -c game.c
I have created my own static library and included the header file path and library path. When I execute my makefile it gives an error saying that
/usr/lib/gcc cannot find -larith -ldekk.
It is pointing to the lib/ directory but it is not over there: -ldekk and -larith are in source1 and source2 files respectively.
How to solve this error?
Instead of -L./cygdrive/c, use -L/cygdrive/c. The dot makes the library path relative from the current directory, i.e. it will look for a cygdrive subfolder of the current folder instead of drive C.
My revised Makefile libraries line is:
LIBS=-L/usr/lib/arm-linux-gnueabihf -lrtlsdr -lpthread -lm
This solved the issue in a Raspberry Pi 4 running the latest Raspbain as of Dec 30, 2019
I'm trying to use the sprintf() function. Therefore I have to include the stdio.h in my C project. If I compile the project without including the stdio.h in my makefile, the compiler generates the error that sprintf() is a unknown function. Including the stdio.h to the makefile generates the error that there is "no rule to make target."
The makefile template gives the options as follows:
NAME = test
CC = arm-none-eabi-gcc
LD = arm-none-eabi-ld -v
AR = arm-none-eabi-ar
AS = arm-none-eabi-as
CP = arm-none-eabi-objcopy
OD = arm-none-eabi-objdump
CFLAGS = -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb
AFLAGS = -ahls -mapcs-32 -o crt.o
ASFLAGS = -Wa,-gstabs
LFLAGS = -Tlinkerscript_rom.cmd -nostartfiles
CPFLAGS = -Obinary
ODFLAGS = -S
I hope that you can help me out, because I have no desire to rewrite every standard function.
Sven
Makefiles don't read include files. The C preprocessor reads include files, before the resulting file is compiled by the compiler. You should include the header in your C file. Just add:
#include <stdio.h>
Somewhere close to the top, before any function definitions etc.
This will show a declaration of the function to the compiler, which will remove the warning.
Just include stdio.h at the top of your c file
#include <stdio.h>
The only reason to put a .h file in your makefile is so that the files dependent upon your header will be recompiled if anything in the header is changed. Needless to say, this is most commonly with header files you have written.
If there is an error after including stdio.h, you have a broken tool chain. If you update your question to indicate your platform, we may be able to help you fix it :)