c++: g++ not seeing library on cmd [duplicate] - c++

I have a project (a library) that is subdivided into a few directories with code in them. I'd like to to have g++ search for header files in the project's root directory, so I can avoid different include paths for same header files across multiple source files.
Mainly, the root/ directory has sub-directories A/, B/ and C/, all of which have .hpp and .cpp files inside. If some source file in A wanted to include file.hpp, which was in B, it would have to do it like this: #include "../B/file.hpp". Same for another source file that was in C. But, if A itself had sub-directories with files that needed file.hpp, then, it would be inconsistent and would cause errors if I decided to move files (because the include path would be "../../B/file.hpp").
Also, this would need to work from other projects as well, which reside outside of root/. I already know that there is an option to manually copy all my header files into a default-search directory, but I'd like to do this the way I described.
Edit: all programs using the library must compile only with g++ prog.cpp lib.a -o prog. That means permanently setting the include path for g++!

A/code.cpp
#include <B/file.hpp>
A/a/code2.cpp
#include <B/file.hpp>
Compile using:
g++ -I /your/source/root /your/source/root/A/code.cpp
g++ -I /your/source/root /your/source/root/A/a/code2.cpp
Edit:
You can use environment variables to change the path g++ looks for header files. From man page:
Some additional environments variables affect the behavior of the
preprocessor.
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH
Each variable's value is a list of directories separated by a special character, much like PATH, in which to look for header
files. The special character, "PATH_SEPARATOR", is target-dependent and determined at GCC build time. For Microsoft Windows-based targets it
is a semicolon, and for almost all other targets it is a colon.
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.
The remaining environment variables apply only when preprocessing the particular language indicated. Each specifies a
list of directories to be
searched as if specified with -isystem, but after any paths given with -isystem options on the command line.
In all these variables, an empty element instructs the compiler to search its current working directory. Empty elements can
appear at the beginning
or end of a path. For instance, if the value of CPATH is ":/special/include", that has the same effect as -I.
-I/special/include.
There are many ways you can change an environment variable. On bash prompt you can do this:
$ export CPATH=/your/source/root
$ g++ /your/source/root/A/code.cpp
$ g++ /your/source/root/A/a/code2.cpp
You can of course add this in your Makefile etc.

gcc -I/path -L/path
-I /path path to include, gcc will find .h files in this path
-L /path contains library files, .a, .so

it's simple, use the "-B" option to add .h files' dir to search path.
E.g. g++ -B /header_file.h your.cpp -o bin/your_command

Headers included with #include <> will be searched in all default directories , but you can also add your own location in the search path with -I command line arg.
I saw your edit you could install your headers in default locations usually
/usr/local/include
libdir/gcc/target/version/include
/usr/target/include
/usr/include
Confirm with compiler docs though.

Related

Can't link a static binary to #include it

Good day,
I have a file that I'm trying to compile and within it has an #include to a statically linked binary.
#!/bin/bash
g++ -Wall -std=c++17 Message.cpp ../textmagic-rest-cpp/lib/libtextmagic.a
I am getting the following error: fatal error: libtextmagic.h: No such file or directory
The relative path that I provided is correct under the assumption that the current working directory is the directory in which the script is called/ran. I might be linking the binary incorrectly and I've searched around the internet but the other posts/resources did not help me.
Note that the script is run in the same directory as Message.cpp.
g++ has the -I and -L flags that do that for you. Your flag will look like this: -I/ThePathToYourHeaders and -L/ThePathToYourLib. I don't know if g++ supports relative paths there but absolut paths are guaranteed to work there.
Also you probably need to add a linker flag. For your project it will be -ltextmagic. It is just the name of the .a file you want to link with, without the lib in front of the filename.
The #include directive needs to "read" the header file you give it as argument, and that is not included in the static library.
You can either include using a relative path to the source file or pass the location of the header file to the compiler using the -I argument.

g++ can't seem to find .h file with or without the -I command line switch [duplicate]

In a "working directory" I have a lot of *.cpp and *.h files that #include each other and files from subdirectories.
For example:
#include "first.h"
#include "second.h"
#include "dir1/third.h"
#include "dir2/fourth.h"
In my own directory (that is different from the "working" directory) I would like to create a new *.cpp and *.h file that includes one of the files from the "working" directory. For example:
#include "/root/workingdirectory/first.h"
However, it does not work. Because "first.h" might include "second.h" and "second.h" is not located in my directory. Is there a way to tell the compiler that it needs to search included files not in the current but in the working directory: /root/workingdirectory/?
To make it even more complex, dir1 and dir2 are not located in my working directory. They are located in /root/workingdirectory2/. So, my second question is if it is possible to resolve this problem by letting compiler know that subdirectories are located somewhere else?
I also need to add, that I do not use any environment for development and compile from the command line (using g++).
As you've already been told, it's useful to read the manual - specifically this chapter - and even more specifically right here.
Specifically, you want
g++ -I/root/workingdirectory -I/root/workingdirectory2
Note also the documentation on #include directive syntax, described here as:
2.1 Include Syntax
Both user and system header files are included using the preprocessing
directive #include. It has two variants:
#include <file>
This variant is used for system header files. It searches for a file named file in a standard list of system directories. You can prepend directories to this list with the -I
option (see Invocation).
#include "file"
This variant is used for header files of your own program. It searches for a file named file first in the directory
containing the current file, then in the quote directories and then
the same directories used for <file>. You can prepend directories to
the list of quote directories with the -iquote option. The argument of
#include, whether delimited with quote marks or angle brackets,
behaves like a string constant in that comments are not recognized,
and macro names are not expanded. Thus,#include <x/*y> specifies
inclusion of a system header file named x/*y.
However, if backslashes occur within file, they are considered
ordinary text characters, not escape characters. None of the character
escape sequences appropriate to string constants in C are processed.
Thus, #include "x\n\\y" specifies a filename containing three
backslashes. (Some systems interpret \ as a pathname separator. All
of these also interpret / the same way. It is most portable to use
only /.)
It is an error if there is anything (other than comments) on the line
after the file name.
So for example
#include "first.h"
will start looking in the same directory as the .cpp file containing this directive (or take a relative path as relative to this directory).
If you want to use the include path (specified by -I) you should use
#include <dir1/third.h>
Usual practice is to use the #include "local.h" form for headers inside a library/package/module (however you've chosen to organize that), and the #include <external.h> form for headers from external/3rd-party or system libraries.
Read The Fine Manual
It's there for everyone to read. You even have a choice of what to use (I'd go with the first):
-Idir
Add the directory dir to the head of the list of directories to be searched for header files. This can be used to override a system header file, substituting your own version, since these directories are searched before the system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files (use -isystem for that). If you use more than one -I option, the directories are scanned in left-to-right order; the standard system directories come after.
If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC's procedure to fix buggy system headers and the ordering for the include_next directive are not inadvertently changed. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options.
-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.
For gcc it is the -I option for header includes. For the .cpp files you just need those to appear as an argument to the gcc command.
Every C/C++ compiler (g++, gcc, MinGW, clang, e.t.c.) has a folder called "include" in it's root path where it automatically looks for header files. If you use MinGW, it would be in, for example: "C:\MinGW\include". Just save your header to the include folder like this: C:\MinGW\include\header1.h or C:\MinGW\include\LibGUI\Window.h

I am getting compiler errors while compiling my code in unix

i have two folders named Source and powerserver in my home directory. In source direectory i have some code related to project and it uses a .h header file from power server directory. when am compiling using make -f somename.lnx32 I am getting the below error.
error: cst.h no such file or directory.
I am new to this i dont know how to access that .h file ?
GCC looks in several different places for headers. On a normal Unix system, if you do not instruct it otherwise, it will search in default directories.
You can add directories to this list with the -I command-line option. All the directories named by -I are searched, in left-to-right order, before the default directories.
Try gcc -c -I/path_to_powerserver_directory to include header files in GCC search path.
Currently this particular header file is not found to gcc in it's search paths.
It's tagged Linux so i guess you use GCC.
#include <someheader.h> means to search someheader.h in system directories (ie. /usr/include), which you can override using the -Ipath option with GCC.
But in your case, you should be using #include "someheader.h" with the correct user path in your Makefile with the -iquote option.

GCC compiler cannot find hpp files

I am trying to install the hep-mc library listed here: https://github.com/cschwan/hep-mc for use on compute using the instructions listed in the documentation here: https://github.com/cschwan/hep-mc#installation . To compile one of the example files, I typed this into the terminal:
g++ -L/usr/local/hep-mc/include vegas_mpi_ex.cpp -o vegas_mpi
but I get these error messages:
mpi_vegas_ex.cpp:1:22: error: hep/mc.hpp: No such file or directory
mpi_vegas_ex.cpp:2:26: error: hep/mc-mpi.hpp: No such file or directory
mpi_vegas_ex.cpp:8:17: error: mpi.h: No such file or directory
in the beginning of my code, the declarations are like this:
#include "hep/mc.hpp"
#include "hep/mc-mpi.hpp"
#include <mpi.h>
The tutorial states that I should point the compiler to the location of the "include" folder that contains all the .hpp files, which I have done. Do you guys have any idea as to what I'm doing wrong?
It should also be noted that the compiler cannot find the mpi.h directory even though I have loaded the openmpi module.
-L sets paths where the linker searches for libraries to link. The option you're looking for is -I, which sets the paths where the compiler searches for #included files.
g++ -L/usr/local/hep-mc/include vegas_mpi_ex.cpp -o vegas_mpi
Oops!
g++ -I/usr/local/hep-mc/include vegas_mpi_ex.cpp -o vegas_mpi
-L specifies the path to library files; -I specifies the path to includes.
This is confusing because in terms of project management and distribution, we consider "the library" to include both binaries and header files, as well as documentation and all sorts of goodies. But at a technical level that is not what "library" means.

Which directories does include statement search in C/C++?

test.c:
#include "file.h"
In the above statement, which directories will be searched ?
I suppose the directory where test.c locates will be searched, right?
But is that all?
BTW, what's the benefit to use a header file? Java doesn't require a header file...
#include <header_name>: Standard include file: look in standard paths (system include paths setup for the compiler) first
#include "header_name": Look in current path first, then in include path (project specific lookup paths)
The benefit of using a header file is to provide others with the interface of your library, without the implementation. Java does not require it because java bytecode or jar is able to describe itself (reflexion). C code cannot (yet) do it.
In Java you would only need the jar and have the correct use statement. In C you will (mostly) need a header and a lib file (or header and dll).
The other reason is the way c code is compiled. The compiler compiles translation units (a c/cpp file with all included headers) and the linker in a second step links the whole stuff. Declarations must not be compiled, and this saves time and avoid code to be useless generated for each compilation unit which the linker would have to cleanup.
This is just a general idea, I am not a compiler specialist but should help a bit.
It's controlled by your compiler. For example, gcc has a -I option to specify the include path.
C and C++ prototypes are required so the compiler (distinguished from the linker) can make sure functions are being called with the correct arguments. Java is different in that the compiler uses the binary .class files (which unlike C are in a standard bytecode format with all type information preserved) to check that calls are valid.
Using quotes after the #include instructs the preprocessor to look for include files in the same directory of the file that contains the #include statement, and then in the directories of any files that include (#include) that file. The preprocessor then searches along the path specified by the /I compiler option, then along paths specified by the INCLUDE environment variable.
If you use the angle bracket form, it instructs the preprocessor to search for include files first along the path specified by the /I compiler option, then, when compiling from the command line, along the path specified by the INCLUDE environment variable.
The C++ Standard doesn't really say which directories should be searched. This is how the C++ Standard describes what happens when #include "somefile.h" is encountered:
A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that
directive by the entire contents of
the source file identified by the
specified sequence between the "
delimiters. The named source file is
searched for in an
implementation-defined manner. If this
search is not supported, or if the
search fails, the directive is
reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence
(including > characters, if any) from
the original directive.
So exactly what directories are searched are at the mercy of your specific C++ implementation.
strace, or truss, etc., may be helpful. For example, create a file foo.c with the single line #include "foo.h". Then on CYGWIN, the command:
strace /usr/bin/gcc-4.exe foo.c | grep 'src_path.*foo.h,' | sed 's/.*src_path //;s/foo.h.*//'
produces:
foo.c:1:22: error: foo.h: No such file or directory
/home/Joe/src/utilities/
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include/
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include-fixed/
/usr/include/
/usr/include/w32api/
I was actually surprised this list was so short: the last time I did this exercise, on SunOS 4 fifteen years ago, the search path had over a dozen directories.
The first directory, obviously, is where foo.c lives. See aslo http://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html for the environment variables CPATH and C_INCLUDE_PATH. But these are not set on my machine. (And I am unclear whether CYGWIN uses them, anyway.)
Edit: The simplest solution is to use cpp -v (not gcc -v). It gives:
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=i686'
/usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe -E -quiet -v -D__CYGWIN32__ -D__CYGWIN__
-Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../..
/include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib/../../include/w32api -
-mtune=generic -march=i686
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/include"
ignoring duplicate directory "/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include
/usr/lib/gcc/i686-pc-cygwin/4.3.4/include-fixed
/usr/include
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../include/w32api
End of search list.