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.
Related
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.
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.
Are C++ Lib Files binary, or just some sort of container, like a zip file, which contains all of the binary files?
I ask, because I'm curious if I can open a library file (.lib) to get more information about what files are inside of it, similar to how you can open a jar file and look through it in a human readable way.
I ask, because I'm adding some libraries to my lib path and would prefer to know if the lib files contain the classes I'm trying to reference.
As far as I know, a library file is pure binary. So it's impossible to actually 'see' it's contents like a zip file.
If you got hold of some .lib files then it's probable it also came with documentation that explains it's functionality. That would be a good place to check if your classes are present in the library.
EDIT: This question describes a lib file inspector called dumpbin, might be what you need.
A lib file contains the compiled binary of all of the compilation units that are provided by the library. Since you have tagged C++Builder, I assume you have OMF-libraries. You can easily get quite a lot of information out of these, for example all function signatures in the library.
C++Builder ships with a tool called TDump that prints contents of the library in human-readable form. It's located in the bin-directory under the C++Builder installation directory.
The example below shows you how to use TDump to dump contents of a library from the command line:
"C:\Program Files\Embarcadero\RAD Studio\10.0\bin\tdump.exe" library.lib > library-dump.txt
You can find each object module in the library by searching the output for "THEADR". After the THEADR-line you will have a list of all of the dependency files (basically includes) used when the object was compiled. After the dependencies there are the symbols, including demangled function signatures.
I'm trying to write an Arduino library (effectively a C++ class) which itself references another library I have installed in my Mac's ~/Documents/Arduino/libraries directory.
At the top of the .cpp of the library I'm writing, I've tried
#include <ReferencedLibrary.h>
and
#include "ReferencedLibrary.h"
... neither of which work. I can successfully #include <ReferencedLibrary.h> from sketches in my ~/Documents/Arduino directory. Am I missing something or is this a limitation of the Arduino IDE/makefile? Is there a workaround?
I have been able to include a library in another Arduino library by using a relative path. For example, to include the AbstractSwitch library into the DigitalSwitch library, assuming that both of these libraries live in their own separate folders within Arduino's standard library folder, you can use the following include statement:
#include "../AbstractSwitch/AbstractSwitch.h"
In other words, your include statement should read:
#include "../LibraryFolder/LibraryHeaderFile.h"
The documentation here https://github.com/arduino/Arduino/wiki/Build-Process states:
The include path includes the sketch's
directory, the target directory
(/hardware/core//) and
the avr include directory
(/hardware/tools/avr/avr/include/),
as well as any library directories (in
/hardware/libraries/) which
contain a header file which is
included by the main sketch file.
This means that if you #include "ReferencedLibrary.h" from your main sketch file, this causes that file's libraries directory to get added to the include path for other libraries to include. A bit of a hack but it does work on my Mac.
This issue was solved in the Arduino 1.6.6 release. The release notes of 1.6.6 mention that library to library dependencies have been fixed.
Library to library dependencies: when your sketch imports a library, and that library uses another, the IDE will find out without you having to add a useless #include to your sketch
Updating your version to 1.6.6 or newer will resolve your problem.
Using the Arduino environement, as I understand it, you cannot access your own library from another of your own libraries. There is no way to add paths, so there is simply no way for the compiler to find the code. That makes it hard to write libraries that use code in another of your libraries. My web research indicates this has been a problem for years but to my knowledge has not been solved. I suspect there are difficulties in the implementation details or perhaps a desire to keep the system simple at the expense of capability.
Of course, you can always cut and paste code into each new library, but that's exceedingly sub-optimal. You can also write one huge library with all of your code in one pair of .h and .cpp files. That's also not very satisfactory, but I've done it on occasion.
There is a work around, however, for using standard Arduino libraries in your own library that you're placing in your sketchbook/libraries directory. Since sketches include paths to the standard library locations, and link the standard library code, you can include the header file for the standard library of interest in your sketch. Below that, also in your sketch, include your own library header file. The standard library will then become available to your library as well as to your sketch.
Not recommended method: It is possible to add basically any external library code to Arduino IDE build by knifing boards.txt file. Headers in c/cpp flags and libraries in ld flags. This may be useful for library dev using external tools (cmake/QT creator for me today).
I modified /home/pekka/arduino-1.8.5/hardware/teensy/avr/boards.txt by adding "/coderoot" to gcc include path and E_OS_arduino define, modified lines below:
teensy36.build.flags.cpp=-fno-exceptions -felide-constructors -std=gnu++14 -Wno-error=narrowing -fno-rtti -I/coderoot -DE_OS_arduino
teensy36.build.flags.c=-I/coderoot -DE_OS_arduino
I have been learning opengl for about 4-5 months now.
I am ready to stop using glut(a helper library that obfuscates many difficult / tedious aspects of opengl programming )
Problem is, I feel I have removed all refrences to glut.h, as well as all function calls within glut, but when I run my application it is still trying to link to glut32.dll.
Generally so I and others can learn for later,
How can I tell which libraries an excutable/source-code need and why(function/header wise), either before or after compile?
I am using VS2010 but cross compiling this on a linux box with g++
In this specific instance I don't have the dll listed as an additional dependency . But I do see glut.h in the extrenal dependencies folder...i just cant remove it
Thank you
Dependency Walker is your friend for examining the dll dependencies of compiled binaries.
The principal problem is of course, you have added glut.lib or glut32.lib to your project someplace. Its probably in the Project Properties > Linker Settings > Additional Libraries, or some source file contains a #pragma something like this :-
#pragma comment(lib, "glut32.lib")
Look at the linker properties for you project(s). The dll, or rather, the corresponding .lib should be listed there under "additional dependencies".
Edit:
By the way, including a header and linking a library (or a dll) are two different things. You may be including a header somewhere, but not linking to the corresponding library. In that case, the linker will give you an error. On the other hand, you may not be including the header, and not using the library at all, but you may still be linking to it.
In this case it seems like we have both. If glut.h is in the external dependencies folder then you must be including it somewhere in your code. Try using find-in-files to look for it. Or delete it from your system altogether and try to compile.
Every exe/dll has something called an Import Address Table (IAT) which is information stored in the PE (Portable Executable: window's executable file format) file's header about what dlls the loader needs to load when the module in question is loaded. You can use tools like PE Viewer or PE Explorer to view this information or write your own (this is more difficult). What you will see are libraries that are statically linked to your executable. If you don't see glut32.dll in any of those files, it is possible that it is loaded dynamically through LoadLibrary api in some other openGL library. I am not very familiar with openGL binaries, so I cannot confirm this for you.
If you have problems to find where glut.lib is hidden in the visual studio project options, open the .vcproj in a standard text editor and make a full text search.