In c/c++ we use -I for specifying header files location and -L path for specifying library path. I have an eigen and boost libraries, so what I did is that I copied these libraries to /usr/include directory in linux and in source file of my program I just used the header file of these libraries. My question is how does the source file of these libraries get linked with my program source file in which I am only using header files of these libraries?
It depends on the libraries you are using. Eigen3 is header-only: no need to link against it. With Boost, it depends. Most parts are header-only but some libraries might need to be linked.
On the copying to /usr/include. This sounds horribly wrong. Use the package manager of your distribution to get a package of the libraries you require. You should almost never put files yourself into /usr/{include|lib...} directly but prefer /usr/local/{include|lib...}.
You are also a little confused about source code and object code. Generally, a library will contain compiled, object, code, but C++ template expansion requires some kind of source code or source-like code in order to perform template instantiation.
However, the bottom line is that the syntax to include a library depends on the compiler/linker combination you are using. You need to state that before someone can answer the question fully.
The directory "/usr/include" is considered special, part of the operating system or platform you are using, so you should not copy files into it.
Note that the construction "c/c++" is not very meaningful - the two languages C and C++ have different syntax and different linkage models. Best to say which one you meant.
Related
I am working with some autogenerated C++ code provided by a vendor. They use the Boost libraries extensively, and as such I also need to use the boost libraries in order to create the appropriate objects to send as inputs to vendor methods. They provide all the Boost header files within a lib folder in the autogenerated code.
I have never used Boost before, but from what I've gathered in the past few days it is for the most part a header only library, which to me means that there are no *.dlls or *.lib files required to use it in my software provided I don't use the listed features that do require a lib file.
The problem I am having is when I try to include "boost\date_time.hpp" when it comes time to build it I get a LNK1104 error "cannot open file libboost_date_time-vc140-mt-gd-1_38.lib". I have noted that on the Boost website it says that some libraries do have optional compiled libraries depending on if certain features are used; for date_time it says the following:
"Boost.DateTime has a binary component that is only needed if you're using its to_string/from_string or serialization features, or if you're targeting Visual C++ 6.x or Borland."
I do not require any of the features that would require a compiled library, and have not referenced any features at all yet in my code, simply added the include. So why is it demanding this file? Also, how does it even know what file to demand? Is there a sneaky #pragma hidden in one of the header files? I started to look but there were too many paths to go down.
The vendor does supply a compiled dll and lib file for Boost.DateTime, however it is named 'boost_date_time-vc140-mt-gd-1_38.lib', the file the compiler is looking for has 'lib' prefixed to the front. If it does require it, then how can I direct the linker to the correct file? I know I can change the name of the file to what the linker is looking for (the linker has the path to the folder containing the file already, it is nothing to do with that) but as this code comes from the vendor code generation software it will frequently revert back to the original file name, so that would not be an optimal solution.
As always, thank you for any help you can provide.
As tkausl mentioned in the comments there was a #pragma comment in a header file trying to load the lib.
By adding the line '#define BOOST_ALL_NO_LIB' before the '#include "boost\date_time.hpp"' line this solved the problem as the defined Macro tells Boost to not to load the lib file.
I am building a C++ project on my Ubuntu 64bit system using a provided Makefile, and this project also provides an API library for developers.
The compilation was successful, no errors at all, but when I try to include in my files the API libraries provided in the "api" folder, then g++ complains about undefined references.
It is not a problem about dependencies (I already built the project succesfully), in fact the missing references are about classes and functions provided by the project, but they are in some specific (sub-)folders (I don't know which ones!), I guess in some .so files, and g++ is not finding them, probably because it does not know they are in those specific subfolders.
It is not the first time this happens when trying to use APIs from any project, then I think I am missing something or I am doing something wrong in general when trying to use the libraries provided in a project.
In particular, the main problem is that I don't know how to tell the compiler where some classes or data structures are declared, and moreover I don't know how to locate them in order to know where they are.
Usually, a workaround I use to avoid this problem is to run make install (as root or using sudo) so that libraries and APIs are installed in standard folders (like /usr/include or /usr/lib) and if I do this thend I can include the API libraries using #include <library>, but in this last case it didn't work either, because perhaps some required files containing the not found classes/structures are not properly installed in the right folders in the system.
Another workaround I used sometimes is to try to put all the project files in the same folder instead of using the project folder structure, but clearly this is not good! :-)
But I noticed that several other people managed to use the APIs, then apparently they know some way of finding the files containing the "undefined" references and including them in the compilation.
Then my general question is: given a "classic" C++ project based on "Makefile" files and with usual folder names like src, lib, build, bin, etc., if I want to write C++ files using the libraries provided by the project, but the compiler complains about undefined references, how can I find the files (.so or .o or .cpp) containing such references? Is there any tool to find them? And how can I tell the compiler where they are? Should I use some command-line option for g++ or should I use the #include macro in some smart way?
PS I also tried to use the pkc-config linux tool to get right options to use for compilation and they were available, but the compiler still complains about the undefined references.
Some more degails about the project i tried:
For interested people a link to the project is below:
https://github.com/dreal/dreal3
And instructions on how to build it:
http://dreal.github.io/download/
Look into the -rpath linker option - specifically with the "$ORIGIN" argument. That lets you find libraries relative to your executable location so you don't have to install them to the standard locations but just need to put them somewhere known, relative to the executable. That should help you with one piece of the puzzle.
Note: -Wl, can be used to pass arguments to the linker via g++.
As for pointing the compiler/linker at a library so it can resolve undefined references by using that library, use the -l (that's lowercase L) option to specify the library name and -L to specify directories to search for libraries.
As for looking into a library (.so) file to see what symbols are in there, you have a few tools at your disposal: objdump, nm, readelf and objcopy.
I am using Boost in an Xcode and have to add the .dylib files that contain the functionality that is used. Some of them makes perfect sense from the naming e.g. libboost_signals.dylib for using signals. But i can't find the .dylib to include for stuff like mpl and Boost.type_traits. I have searched the web but it didn't give me anything. Could somebody point me in the right direction?
Some of boost libraries are header only. That means that they consist only of header files, so they have no dylib's (so's on linux and dll's on windows). If you deal with templates you can't compile them beforehand: you have to provide source code which will be instantiated with proper types and compiled in-to a object file which uses them.
mpl and type_traits are header only so you don't need to add any additional dylib's to your project.
You can explore symbols inside libraries using nm, for example, try running nm libboost_signals.dylib
I am learning C++ and, in order to do so, am writing a sample wxWidgets application.
However, none of the documentation I can find on the wxWidgets website tell me what library names to pass to the linker.
Now, apart from wxWidgets, is there a general rule of thumb or some other convention by which I should/would know, for any library, what the names of the object files are against which I am linking?
We have more of a "rule of ring finger", instead of a thumb
Generally, if you compile the library by hand, it will produce several library files (usually .a .lib or something similar, depending entirely on your compiler and your ./configure) these are produced (typically) because of a makefile's build script.
Now a makefile can be edited in any way the developer pleases, but there are some good conventions (there is, in fact, a standard) many follow- and there are tools to auto generate the make files for the library (see automake)
Makefiles are usually consistent
You can simply use the makefile to generate the files, and if it's compliant, the files will be placed in a particular folder (the lib folder I believe?) all queued up and ready to use!
Keep in mind, a library file is simply the implementation of your code in precompiled format, you could create a library yourself from your code quite easily using the ar tool. Because it is code, just like any other code, you don't necessarily want to include all of the library files for a given library. For instance with wxWidgets if you're not using rich text, you certainly don't want to waste the extra space in your end executable by including that library file. Later if you want to use it, you can add it to your project (just like adding a .cpp file)
Oh and also with wxWidgets, in their (fantastic) documentation, each module will say what header you need to include, and what library it is a part of.
Happiness
Libraries are amazing, magical, unicorns of happiness. Just try not to get too frustrated with them and they'll prance in the field of your imagination for the rest of your programming career!
After a bit more Googling, I found a page on the wxWidgets wiki which relates to the Code::Blocks IDE, but which also works for me. By adding the following to the linker options, it picks up all the necessary files to link:
`wx-config --libs`
(So that does not solve my "general rule" problem; for any library I am working with, I still have to find out what files to link against, but at least this solves the problem for wxWidgets).
The build instructions are different for each platform and so you need to refer to the platform-specific files such as docs/gtk/install.txt (which mentions wx-config) or docs/msw/install.txt to find them.
FWIW wxWidgets project would also definitely gratefully accept any patches to the main manual improving the organization of the docs.
I'm new to C++. I just downloaded the Boost libraries to study. I wanted to look into some implementation details, so I looked for .cpp files. To my surprise, I haven't found any so far.
There seem only .hpp files out there. Where are the .cpp files?
From the Boost documentation:
Most Boost libraries are header-only: they consist entirely of header
files containing templates and inline functions, and require no
separately-compiled library binaries or special treatment when
linking.
See that link for the list of libraries that are not header-only and must be built separately. For those libraries, the .cpp files are in the /libs directory of the Boost distribution. If you got the precompiled package, you'll instead find the already-compiled .lib files in the /lib directory.
The .hpp files are the headers that you must include in your code in order to use Boost classes. Many Boost libraries are header-only; all of the implementations are in the .hpp files. For those that do have source, you only see the compiled versions as .lib files.
If you download a source distribution of Boost, it should have several subdirectories:
boost: contains .hpp headers
lib: contains .lib files (compiled implementation details)
libs: the source of those implementation details
Because many (but not all) of the libraries are implemented using templates, and must therefore be placed within header files.
A lot of the Boost library are purely template. In the previous standard of C++ there was already the keyword export to allow the developer to separate the implementation from the interface.
The sad truth was that the keyword never worked completely (difficult to implement from the compiler vendor point of view and difficult to use it right for the developer). One way to fix the problem was provide interface and implementation in a header file and avoid the implementation file. By the way, there are several Boost libraries that you need to compile and link in order to use it, and I bet you will find implementation files in those libraries.
For those which aren't header-only, the source files can be found inside the libs sub directory.
I believe the majority of the Boost libraries are implemented in the actual header files only, as previous posters mentioned. As was also mentioned, compiled implementation code will be included as separate library files when separate from the header files.
You mentioned being new to C++, so I think it's worth mentioning that this type of library distribution is not particular to Boost. Other third party libraries and APIs you use will likely be structured in the same way; you will find packages of header files and library files only, with no .c, .cxx, .cpp, etc files. This is done for a number of reasons, including to hide the implementation of the library functionality, and to allow shared libraries to be loaded into memory once each.
This article might help clarify things for you:
http://www.learncpp.com/cpp-tutorial/a1-static-and-dynamic-libraries/
You are probably looking at precompiled package, where cpp files are available in shape of libraries, not source. If you actually grab the source you will find some cpp files.