I have two versions of boost installed, one in ~/local_opt/ and one in /usr/include. I would like to use the former one, after it provides some newer functions. Thus I am compiling my program with
g++ -I/home/<>/local_opt/boost/include main.cpp
Nevertheless it fails with
/home/<>/local_opt/boost/include/boost/math/interpolators/cubic_b_spline.hpp:25:69: fatal error: boost/math/interpolators/detail/cubic_b_spline_detail.hpp: No such file or directory
Thus I assume that it still tries to use the boost functions in /usr/include, and not my own version of boost. Why? How can I override the search path properly?
Related
I want to set up GLFW3 to work with C++ in a program called 4coder. I have a folder named libraries that holds all the stuff I need, I just don't know how to get C++ to include them using #include <GLFW/glfw3.h>. I literally started using C++ today and have no idea where to start.
You will need to add arguments when compiling the source code to specify the location of your headers and libraries. Exactly how this is done will depend on which compiler you are using but for example if you're using g++:
path-to-working directory>g++ name-of-file.cpp -Ipath-to-header-files -Lpath-to-library-files -lglfw3 -o name-of-executable
The key points here are the -I flag (which tells the compiler where to look for header files) and the -L flag (which tells the compiler where to look for libraries). -lglfw3 will then cause the compiler to look in the directory specified with the -L flag for the glfw3 library.
If you're using a different compiler, the syntax may be different but the general principle will apply - you just have to find the equivalent commands to -I and -L.
I've found that a small C++ project, with no dependencies, won't compile under Cygwin with either GCC or Clang. Under Ubuntu there are no problems; and I've been working with this code for a couple of years. I'll introduce a MWE.
The problem arises when including a header in a subdirectory, which itself includes another header, found in that same subdirectory, but specified with the subdirectory in the path provided to the include directive. Executing the following commands can replicate the error:
mkdir foo
echo \#include \"foo/includes.hpp\" > inc.hpp
echo \#include \"foo/bar.hpp\" > foo/includes.hpp
touch foo/bar.hpp
g++ -c inc.hpp
On 64-bit Ubuntu 18.10, the final GCC (or Clang) invocation will produce no errors. On 64-bit Cygwin under Windows 10, the following error message is displayed.
In file included from inc.hpp:1:0:
foo/includes.hpp:1:10: fatal error: foo/bar.hpp: No such file or directory
#include "foo/bar.hpp"
^~~~~~~~~~~~~
compilation terminated.
Can anyone shed some light on the issue? (By the way, I myself do well understand how to properly include header files - this is about the difference between Cygwin and Ubuntu.)
foo/includes.hppshould have local includes if you use "".
That would be:
#include "bar.hpp"
The specification for what paths are used for searching headers is custom for all compilers, although includes with "" should be considered as local for the file where you have the include, not the one that you are compiling.
Basically, it's:
look in the current folder of the current header being processed for a file with that name
use the same paths as <>after
Of course, as I've said, this could change for a new compiler one day. But it is quite safe to assume that this is the behavior for all compilers (What is the difference between #include <filename> and #include "filename"?).
I have 'correctly' installed gsl on mac 10.13.2.
In my c++ program, I am calling like usual, for example:
#include <gsl/gsl_math.h>
However while running the code, it can not find the gsl.
fatal error: 'gsl/gsl_math.h' file not found
I was wondering how to correctly link gsl PATH and libraries.
I have tried,
setting PATH and LD_LIBRARY_PATH in .bash_profile
setting PKG_CONFIG_PATH to .../Gsl2.3/lib/pkgconfig
$which gsl-config returns
/Users/gkdgoutam/Softwares/HEP_Softwares/Install/Gsl2.3/bin/gsl-config
$pkg-config --libs gsl returns
-L/Users/gkdgoutam/Softwares/HEP_Softwares/Install/Gsl2.3/lib -lgsl -lgslcblas -lm
The only solution I can find is to run everytime with gsl linked.
Like:
g++ $(gsl-config --cflags) mycode.cc $(gsl-config --libs) && ./a.out
But I was wondering if the GSL PATH can be set globally so that I can simply run
g++ mycode.cc && ./a.out
This is how c++ code is compiled and built:
COMPILATION
A compilation unit will take each cpp file and work its way through included headers to locate forward declaration of implementations of symbol signatures of used functionality in your code. In your case this involves gsl/gsl.h. If the file cannot be found in the search directories, which you can expand by specifying C_INCLUDE_PATH and or CPLUS_INCLUDE_PATH. If you omit #include <gsl/gsl_math.h>, your code will not compile as there are signatures, which cannot be found for GSL functions, which you use.
LINKING
Once you have compiled all cpp/cc files you need to link the binary, which can be executed. The linking process consists of a search through all symbols in your .o/.obj... files and a matching of the same to what it can find in your object files and the libraries, which you have specified using for example -lgsl. If all goes well, every lookup finds an according binary implementation for your machine's hardware model (i.e. 64bit/32bit ..., Arm, Intel, ... etc). If some are not found you will find linkage errors.
What you are asking is, is there a way that C++ does not work as above? No!
If you leave out #include <gsl/gsl.h> or if said file is not found in your search paths, compilation will not work or. If you omit -lgsl, linking will fail. If you find it annoying to write all the above stuff in the command line, write a Makefile to reduce the building process to ideally a simple command: make.
Don't forget, that if you are linking against the shared library version of GSL, you might need specifying LD_LIBARAY_PATH on Linux and DYLD_LIBRARY_PATH on Macs as well.
TLDR: you cannot ask a c++ compiler / linker to work differently as designed.
How do I include glfw.h and link the libraries libglfw.a and libglfadll.a in eclipse juno c++ with MinGW compiler. This is an attempt I made on setting it up:
This is the build command I tried to use:
g++ -o Practice.exe "src\\main.o" "-lC:\\Users\\Kaiden.ZEUS\\Files" & "Folders\\Programming\\C++\\Workspaces\\Practice\\Practice\\lib\\libglfw.a" "-lC:\\Users\\Kaiden.ZEUS\\Files" & "Folders\\Programming\\C++\\Workspaces\\Practice\\Practice\\lib\\libglfwdll.a"
Nothing of this is specific to OpenGL or GLEW, you're dealing with basic programmer craftsmanship skills here: How to configure a compiler linker toolchain to use additional libraries. This is essential knowledge, so please take the patience to properly learn it. The following is just a short list of notes what you should change. But you should really take up some learning material on the compilation and linking process to understand it.
You should place the libraries and headers into system wide directories, but not the standard directories of the compiler suite and configure those as additional search paths for the compiler and linker.
DO NOT put 3rd party library and header files into your project source tree, unless you take proper precautions that it won't interfere with likely installed systemwide instances of them.
Also you must choose between the static or the dynamically linked version of GLFW. If you use both you'll get symbol conflicts (this is something specific to GLFW).
In your build command line you're using the -loption with *directories*. This is wrong, search paths are specified using-L(capital L), while-l(lower l) just specifies library names without the path, prefix and suffix. Also you can replace backslashes` with forward slashes /, saving you some typing, i.e. the \\ escaping to produce a single backslashe to the command. In your case (I shortened the path)
g++ -o Practice.exe "src/main.o" "-LC:/Users/Kaiden.ZEUS/Files/ ... /lib" "-lglfw"
or
g++ -o Practice.exe "src/main.o" "-LC:/Users/Kaiden.ZEUS/Files/ ... /lib" "-lglfwdll"
However this compile command lacks specification of the include files. Say you've got the GLEW headers installed in C:/Users/Kaiden.ZEUS/Files/ ... /include/GL you'd add
"-IC:/Users/Kaiden.ZEUS/Files/ ... /include/GL"
to the command line.
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.