I have a small library project that uses OpenGL (glfw and glew). Now, the project compiles fine, but when I create a new project and statically link the library project, VS starts to throw errors in the library project. Why is that?
More specifically, I get this error:
error C1083: Cannot open include file 'GL/glew.h': No such file or directory (file: trenums3d.h)
The project setup is like this: There's the library project 'Foo', which is compiled into a static library ('Foo.lib'). The application project 'Bar' links 'Foo' (I added the folder where Foo.lib resides to Bar's 'Additional Library Directories', as well as the source folder of 'Foo' to Bar's 'Additional Include Directories'). If I compile only the library project, everything works just fine, but compiling the whole solution give me the aforementioned error.
This isn't a proper answer to your question, but just an explanation of the steps required for building an application in a compiled language.
Building a project containing multiple files is a three-step process:
Creation and editing of source and header files
Compilation of the source files (this step contains many sub-steps). This step creates object files of all translation units
Linking of all object files and libraries to form the final executable
Error like the one shown in your question is emitted in the second step. Linking with libraries happens in a completely different step, and is usually done by a different program than the compiler.
To answer your question, if linking with a static library also requires linking with the other libraries that the static library depend on, then the answer is normally yes. Static libraries only contain the function in the actual libraries, you can look at a static library more as a collection or archive of object files. Static libraries does not contain any information about other libraries they depend on.
And as for your problem, with the pre-processor error, it's because you include a header file from your static library, and that header file in turn includes some header files. But the pre-processor doesn't have the secondary included header files in its default search path, so you need to add it.
This still have nothing to do with linking any library, this is a pure pre-processor issue, and is handled in step two in my list above.
I suspect the header files of your static library look like somewhat this:
#ifndef SOMECLASS_H
#define SOMECLASS_H
#include "GL/glew.h"
// ...
#endif
If you include this header file from another library or application, the compiler will open this file and will see that it needs to open GL/glew.h as well in order to be able to "understand" the definition of your class.
This means you need to supply at least the header files of glew. The only way to get rid of this is if you manage to only reference glew files from your .cpp files but not from your .h files. In some cases, forward declarations can be used, but not sure if this will work for glew.
Concerning the linker settings: In case your glew library is built statically as well, you may or may not have to supply that library file and link to it from your project. This depends on how you setup your linker for your own static library. If you have troubles in this step, create a new question.
Related
How are we supposed to create a DLL, included with header files?
For example, a project using the raylib game library requires raylib.dll to be present with the output file.
The raylib.dll is included with the header files of the raylib game library.
Is that how are supposed to create a DLL and include header files into it?
I am using Dev C++ with a GCC compiler.
There's only a limited relation between the header files and the creation of the DLL. In particular, you use the word "linked", and header files are not linked. Header files are included, libraries are linked. Including happens before a compile, linking afterwards.
Header files can provide declarations for functions defined in the DLL. That tells the compiler that those functions actually exist (somewhere), so the compiler will ask the linker to find those functions. The linker in turn will find them in the library.
I want to ask whether the library.lib file generated when creating a dynamic library contains some kind of memory location reference to the function of the dynamic library?
How exactly does the executable find and resolve the functions either at load time or runtime?
In visual studio, the dynamic library .dll and static library .lib are created by creating a library application, followed by generating the header file and .cpp file representative of the library to be included into other source codes and finally compilation.
The library is then used by another program source code by using the include directive on the header file, then followed by declaring the location to header files of the library under additional include directories. Then settings additional dependencies to the static .lib file generated previously also called DLL import library. A post build event is then set in order to copy the .dll file into the local working directory of the executable.
DLL import library, what exactly is contained in this static library which i guess provides instructions to resolve functions in the dynamic library?
Thanks
I have two C++ projects (proj1 and proj2) in the same solution. How to include the header files from proj1 into proj2? I included those header files in proj2 by setting Additional Include Directories, but cannot link those functions - Error: unresolved externals.
you don't need to from the reference of porj2,add proj1,then the compiler will link proj1 when compile proj2.
So your problem is not the actual inclusion of the header files, it's linking to the object files of the other project.
There are basically two solutions to that problem:
Simply pull in the source file from other project into the project where they are needed. This will cause you to build the source files twice, once for each project. Note that I don't mean you should physically copy the files on disk, just drag and drop the source files in the solution side-bar.
Put common code in a third project, as a library. Then both your projects uses this library, and links with it.
I highly recommend the second solution.
While you are getting linking error that means you have compiled your code successfully and that means that you have included your headers correctly. Congrats! However, you are facing unresolved externals error. This is because you have just tell the compiler where to find the .h file but what about the real code? yes the one in the .cpp?
Options:
Put all your code in .h files which could be a fast solution but not an good idea (unless you need portable solution for templated code).
Build your first project as static library and link with the output .lib file (you could find how to do it by quick googling)
Bring your sources (.h and .cpp) to the other project and build them inside your project (Huge redundancy happened here).
I have two projects, one that creates static library and the other one that is using it.
The first one, create a file called liboutputdevice.a.
When I build it, everything goes OK.
Then I have my second project that uses the library above,
and including #include "outputdevice.h"
and calles to a function:
initdevice("sdfs");
Which is declared on outputdevice.h and ipmlemented in the static library above.
The tester project linked to the first project by going to: Cross g++ Linker, libraries and library search path.
When I'm building that project (The tester, second one), the first one is getting an error, with Undefined reference to 'pthread create'
Suddenly...
(although I included the -lpthread in the compile process of the first project).
Someone can tell what it the problem?
You have to tell your compiler/IDE where the include files are. Notice, that library files (usually with a .lib extension) and include files (.h or .hpp) are not the same. While libraries have to be added to the linker (as you did correctly), the include files must be accessible from the project base directory as well.
If the main path of the includes is not the same as of the project, you have to tell the compiler, were it should look for additional includes.
Usually this is done by the -I option of the compiler call, e.g.
g++ main.cpp -I path/to/other/includes/dir
You can also set it up directly in the project preferences of your IDE.
I'm trying to start a C++ game engine project.
I don't have much knowledge of dll's and lib's but figured the engine itself would be a dll and I would have separate dll projects such as renderer, input, etc that would be used by the engine and the engine dll would be used by the game.
I seem to have the engine project referenced fine in the demo.exe project(by adding a reference and adding the path to additional include directories) but when trying to add a reference to a renderer dll project in the engine dll project I'm getting:
error LNK1104: cannot open file 'MyPath\Renderer.lib' MyPath\LINK
Engine
Why is it mentioning libs?
Many DLLs comes with corresponding LIB libraries, that are only needed at linking stage. So basically there are 2 types of LIB libraries:
Real static library that contains all the object files
Library with only definitions for the linker, this kind of libraries comes with DLLs
So basically you need to link this LIB file in order to be able to work with DLL
So I sorted my problem. As they were new projects they had no methods implemented yet, so no lib was being created, so nothing to reference to..silly me.
One last thing though, I'm having trouble defining the dllimport/dllexport macro for a header file. I'm trying to get it to define dllexport when its the exporting project but say my project is 2 names, e.g "awesome engine" then how do I realise the export macro that apparently is created automatically? Should I use an underscore for the space?
#ifdef AWESOME_ENGINE_EXPORTS // Or AWESOMEENGINE_EXPORTS?
#define DLL __declspec(dllexport)
#else
#define DLL __declspec(dllimport)
#endif
the engine project referenced fine in the demo.exe project(by adding a reference and adding the path to additional include directories)
Some libraries can be linked statically, meaning that you need only header files (.h/.hpp) and .lib files. Other libraries might require dynamic linkage that will result into your program being dependent on some DLL files, but usually you will need to have header files to know what is in those DLLs anyway. Sometimes, which seems to be your case, you need all of them: header files, static libraries and DLLs.
Header files contain declarations, they define the structure of your classes, they declare prototypes of your functions, etc. Static libraries (.lib files) are binaries, that contain definitions of your functions, variables and so on, that need to be resolved at compile time, so when they are missing, the linker will complain. Dynamically linked libraries (DLLs) are binaries as well, but they are resolved at run-time, meaning that the time when you really need them is when you run your program.
Generally,
The library may give you it's APIs in two modes:
Dynamic: Smaller executable file, but needs its DLLs.
Static: Larger executable file, but stand-alone.
First of all, decide how do you want to use that library, statically or dynamically?! Then configure your project which the compiler be able to find header files of that library.
Then if it's necessary add LIB files to your project.
In your case: Check if you added LIB files correctly to your project or makefile, or not?