I have a library A.dll that used google logging library(glog). Now I want to use this library in another project,in my own project I don't want to use glog. I want to just use A.dll, but during compilation, the compiler says that can't find logging.h header!!!
Why this happens?! it is a header that A.dll uses internally and I want to use A's interface not glog. I think that it is enough to include A.h, I don't need logging.h . Am I wrong? any idea that what is the problem?
A.dll is built with MSVC++ 2015 and I am using MSVC++ 2015 in QT Creator.
You haven't included evidence of how and where the glog header files are included in A library.
But we may suppose it is #included in one of the public library header files,
that your project includes to use the library,
so you inderectly get the glog headers dependency.
One of the reasons is that the developers of A library did a bad job and failed in hiding the internal only dependencies.
How to overcame the indirect include dependency?
It depends on how the A library headers are written and if you or the original A library developers can change it to avoid exposure of the internal dependency.
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'm trying to separate some of my code and put it in a shared library that I will be able to use from other places. In the documentation:
http://doc.qt.io/archives/qt-4.7/sharedlibrary.html
They say that you cannot link to other header files. How would I be able to include shared headers into my shared library?
Shared libraries in the context being discussed in the link you provided are .so (shared object) files (.dll, dynamic link library, on Windows), or static (.lib) libraries. Qt provides this kind of library; so do many other vendors/projects. To use them in another application (like yours, for example), you include the headers and link against the library.
What the article is warning about is #includeing header files that a user may not have - i.e. ones that aren't part of your project. Remember, for someone else to use your new "shared library", they need to include the header file(s) that you provide. If that file includes other headers that they don't have, they will get errors.
To avoid this problem, do your #includes in your implementation (.cpp) files; that way, they are hidden from future users. Qt recommends the "pointer-to-implementation" (pimpl) idiom - all the implementation details are hidden from the users of the class, including any and all header files that the implementation depends on.
You can easily do the same thing, even if you don't go all-out with pimpl. The goal is to #include in your header only the absolutely required files, hopefully all of which you provide with your library.
Hey so i'm a little confused on why, in msVS++ 2010 you have to have include directories when all the headers and cpp files are inside the static libray or static library project in my case.
I made the static library project with cmake, and the source file i was told to set it to is the same i'm now told to make the include directory... it seems like I have 2 of the same cpp and header files.. except ones included statically in my sollution... WHY?
Because VS++ while abstracting the underlying implementation does not hide it completely.
Include directories and libraries are targeted at different phase of the process, which are traditionally handled by different programs. Include directories by the preprocessor, libraries by the linker. Those programs are now called (or part of?) VC++, but its interface still shows the underlying structure.
There are systems which allows to mark the needed libraries in the source code (and thus in the header) by the use of pragmas. Those have several disadvantages:
non standard
you can't as easily substitute libraries by another (say debug/instrumented/release, single thread/multi thread, ...)
Header files tell you about the functions you're calling.
Static libraries include the code of the function you're calling, but not information about how to call them.
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
So I create a library. I want to use shared ffmpeg libs. On mac os with xcode. I create project file with premake4. Shall I connectshared libs to my project or shall I only connect includes?
If I understand your question correctly, you're asking if you need both the shared libraries and the headers, or just the headers, for your project to work.
You need both. The libraries are generally were the actual code for the functions and classes declared in the headers lives. Your project will compile just fine with only the headers present, but unless there is corresponding code in a lib or shared lib, you can count on linker errors.
I have to say I'm not familiar with the actual build process on OS X, but I believe the above is inherent to any C/C++ project regardless of OS.
Also, since you're probably working with the Standard Library you might have the impression that all you're doing is #includeing headers (iostream, stdio.h, etc), but the libraries are still there and have been added by default by your IDE.