I am trying to include the UIAutomation.h library in my Code::Blocks client but I think I am doing something wrong. I just typed:
#include <UIAutomation.h>
at top of my program where all my other headers are and I get this error message right away when I compile:
fatal error: UIAutomation.h: No such file or directory
I am a bit of a newb with these things, and I saw some people talk online about a "linker". If a linker has anything to do with me being able to use the UI Automation library, please let me know what is a linker and how do I use it? Otherwise, please let me know what you think I could be doing wrong.
ohh ok so I can do like #include "c:\programfiles\...\UIAutomation.h"??.. do I have to include the <>? like: #include <"c:\blah\blah"> or #include "c:\blah\blah"??
Yes you can do that, but that's very probably a bad idea!
You should better use the -I option of the actual compiler to specify where to search for additional (besides standard) include files:
-I"c:\programfiles\UIAutomation\include"
Also you'll need to set the -L option for the linker to specify where to find the corresponding libraries for UIAutomation:
-L"c:\programfiles\UIAutomation\lib"
and the library itself with the -l<lib> option:
-lUIAutomation
The latter name depends which library files are actually present in the directory specifed with the -L option. The above sample expects to find a file named libUIAutomation.a or libUIAutomation.lib there.
I'm not really experienced with the codeblocks IDE, but from what I remember it allows you to set these options in the project settings.
NOTE:
All the specific option references given above, refer to the actual toolchain used for your codeblocks project. These will apply for the most commonly used toolchains (e.g. like GCC), but may vary for different ones. Though, there- will be certainly equivalent options for the compiler and linker tool used.
Related
There are already many options listed of how to add a path to a C++ compiler so that the #include <...> command works on these paths. However, assume that I have a single file (not an entire project) and I want to add an include path just for this file alone. I'd like to do this via a line of code within the cpp-file (say, as very first line). How is this possible? Why? Because I need to include some header file from another directory which in turn depends also on other header files within that same directory (and I get error messages that these other files could not be found due to the fact that this path was not added to the include-list).
For example:
Let's assume I want to include file_a.h in directory
.../include/extra,
I can do that via
#include <extra/file_a.h>
However, if, e.g., I do not have the extra-directory directly as a sub-directory of include, or the file_a wants to include some other file from somewhere else (maybe even /extra, but it's not a sub directory of include e.g.), then I run into trouble, because then the tracking of directories/dependencies gets hard.
I thought it would be a bad habit to change those directories via compiler, so I thought better solution would be to integrate it into the program, so no matter which compiler I use, it would work anyway without even having to think about afterwards, once specified, which directories I have to add.
Per my understanding you did:
#include <absolute/path/to/header/header.h
or
#include <relative/path/to/header/header.h
But into the header.h some other include are included.
#include <header_1.h>
#include <header_2.h>
[...]
#include <header_n.h>
Those other headers haven't relative/absolute path, so compiler doesn't know how to find them.
To solve this you can use (using gcc) the -I compiler option:
-I dir
Add the directory dir to the list of directories to be searched for header files during preprocessing. [...]
Emphasis mine
So you can use
#include <header.h>
In your file and compile it using
gcc ... -I/path/to/headers ...
When you have to specify one or more include paths in the compile command, you can do it as follows:
g++ -I/path1/to/headers -I/path2/to/headers YourProgram.cpp
Include paths tell the compiler where it finds the files it actually shall include into other files. This is (usually) controlled via compiler options as LPs explained in this answer.
C++ standard does not provide any facilities to do this from within a C++ source file and I am not aware either of any compiler extension of any vendor that would allow doing so, so bad luck...
Now depending on the IDE you are using (hopefully you are using one...), though, you most likely can add include paths for files individually there (would be a strange IDE if it didn't allow...), e. g. with eclipse + GCC, right click the file, select "Properties" -> C/C++ Build -> Tool Settings -> GCC C++ Compiler -> Includes.
Alternatively you could use a make file instead (actually, eclipse in standard settings generates one for you automatically...), which again allows you to set compiler options for each file individually - either written directly by yourself or generated by some other tools facilitating this such as cmake.
I dont want to randomly place libraries in arbitrary order hoping I get the order correct. Is there a systematic way to determine the linker library order in eclipse cdt?
ERROR: cannot find -l{some project}
You are correct saying that -l directives must follow a certain order. However, this error means a different thing. The linker simply failed to find the library file you have specified. Perhaps, you're missing the -L directive which specifies the folder where the linker looks for the library files. E. g.
-L../bin -l{libname}
Ok as long as you got "can not find -lsomething. You should put libsomething.so (or.dll or .a etc, the library) in a directory of your choice and the tell the compiler to look at this directory with compiler flag
-L/path/to/libsomething
Note that the -L flag tell the compiler where to look for libraries and the -l (lowercase) tell it to actaly link the library, so you must provide a path to the former and a library name to the later.
Ok, so it's been a while, and i'm having problems with #includes
So I'm doing
#include "someheader.h"
but it's giving me
fatal error: someheader.h: No such file or directory
It's a system wide library I guess you could say.
I'm running arch linux and I installed the library from the repo, and I think the .h files are in /usr/include.
I could just copy all the header files into the folder my code is in but that would be a hack.
What is the "right" way to do this?
Edit: I wasn't correct by saying the .h files were in /usr/include, what I meant was that the library folder was in there
So, Emile Cormier's answer worked to a certain extent.
The problem now is that there are some include in the header file and it seems from the methods I'm trying to access that those includes are not happening
it's giving my the error
undefined reference to Namespace::Class::method()
Edit:
Ok so the final answer is:
#include <library_name/someheader.h>
And compile with
g++ code.cpp -llibrary_name
Sometimes, header files for a library are installed in /usr/include/library_name, so you have to include like this:
#include <library_name/someheader.h>
Use your file manager (or console commands) to locate the header file on your system and see if you should prefix the header's filename with a directory name.
The undefined reference error you're getting is a linker error. You're getting this error because you're not linking in libsynaptics along with your program, thus the linker cannot find the "implementation" of the libsynaptics functions you're using.
If you're compiling from the command-line with GCC, you must add the -lsynaptics option to link in the libsynaptics library. If you're using an IDE, you must find the place where you can specify libraries to link to and add synaptics. If you're using a makefile, you have to modify your list of linker flags so that it adds -lsynaptics.
Also the -L <path_to_library> flag for the search path needs to be added, so the linker can find the library, unless it's installed in one of the standard linker search paths.
See this tutorial on linking to libraries with GCC.
You'd use #include <someheader.h> for header files in system locations.
#include "someheader.h" would try to include the file someheader.h in the directory of your .c file.
In addition to including the header file, you also need to link in the library, which is done with the -l argument:
g++ -Wall youprogram.cpp -lname_of_library
Not doing so is the reason for the "undefined reference .. " linker errors.
The quick fix is to do use:
#include <someheader.h>
assuming that someheader.h is in the standard include locations (to find it use the command locate someheader.h in a shell. If it is in /usr/include it is in a standard location. If it is in a subdirectory of /usr/include you only need to add the part of the directory up to /usr/include in the #include directive (e.g. #include <fancy_lib/someheader.h>)
However, this is only half of the story. You also will need to set up your build system in a way that locates the given library and adds its include path (the path under which it's header files are stored) to the compiler command (for gcc that is -I/path/to/header). That way you can also build with different versions by configuring them in your build system. If the library is not header-only you will also have to add it to the linker dependencies. How this is achieved in your build system is best found out by consulting its documentation.
I'm trying to add SVL to my project.
Without it I'm getting hundreds of errors (undefined reference...). After adding -lSVL all errors are gone, but gcc says: "cannot find -lSVL". Everything else (SDL, SDL_TTF, SDL_Mixer...) works fine.
You should inform gcc of the path where libsvl.a is installed, for example:
gcc -lsvl -L/my/path/
Also, pay attention to the case if you work under Linux ("SVL" is different from "svl").
There are two parts to adding an external library; you need to tell the compiler[1] where to find the description of the API (i.e., the header files) and you need to tell the linker where to find the implementation of the API (i.e., the library file(s)).
The list of possible locations of the headers is given by the include path, which with a traditional compiler is added to with the -I option. It takes a directory name to add; the directory is one extra place the compiler will look for header files.
The list of possible locations of the library is given by the link path. It's just like the include path, but is added to with -L. Note that you can also (at least normally) give the full path to the library directly on the command line, but this isn't particularly recommended because it tends to embed more information in the executable than is really needed.
The syntax for MSVC is recognizably similar IIRC.
If you're using an IDE, you'll probably have to set these things in the project options, but as long as you remember that you need to set both include and library paths, you'll be able to find your way through.
[1]Strictly, you're telling the preprocessor, but the preprocessor's output is virtually always directed straight into the compiler proper.
I am wondering how compilers on Mac OS X, Windows and Linux know where to find the C header files.
Specifically I am wondering how it knows where to find the #include with the <> brackets.
#include "/Users/Brock/Desktop/Myfile.h" // absolute reference
#include <stdio.h> // system relative reference?
I assume there is a text file on the system that it consults. How does it know where to look for the headers? Is it possible to modify this file, if so where does this file reside on the operating system?
When the compiler is built, it knows about a few standard locations to look for header file. Some of them are independent of where the compiler is installed (such as /usr/include, /usr/local/include, etc.) and some of the are based on where the compiler is installed (which for gcc, is controlled by the --prefix option when running configure).
Locations like /usr/include are well known and 'knowledge' of that location is built into gcc. Locations like /usr/local/include is not considered completely standard and can be set when gcc is built with the --with-local-prefix option of configure.
That said, you can add new directories for where to search for include files using the compiler -I command line option. When trying to include a file, it will look in the directories specified with the -I flag before the directories I talked about in the first paragraph.
The OS does not know where look for these files — the compiler does (or more accurately, the preprocessor). It has a set of search paths where it knows to look for headers, much like your command shell has a set of places where it will look for programs to execute when you type in a name. The GCC documentation explains how that compiler does it and how these search paths can be changed.
The location of the file is system dependent. Indeed, the file might be precompiled, or it may not even exist—the compiler may have it as a 'built-in'. On my macbook, I see that there's such a file in /usr/include/c++/4.2.1/iostream, but you shouldn't rely on it, and it's definitely a bad idea to edit it.
If you were using g++, you could do something like this to find out what include paths were searched:
touch empty.cpp
g++ -v empty.cpp
I don't know if there's an equivalent for Xcode. Maybe that will work since Xcode is based on GCC?
In Visual Studio, it's either in the project settings if you use the IDE, or in the %INCLUDE% environment variable if you use the command line.
You should avoid #include-ing files using absolute paths. The compiler searches for the include files in various directories and includes files, starting from each directory. For example;
#include <boost/tokenizer.hpp>
Works because the boost root directory contains a folder called 'boost' and that folder is either in your default include path or you did something like.
g++ -I$BOOST_ROOT {blah, blah}
It is C and C++ standard that the UNIX separator '/' will work the same way for all systems, regardless of what the host system actually uses to denote directories. As others of mentioned, occasionally #include doesn't actually include a real file at all.