This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed 8 years ago.
I have a small console application that makes use of the MySql C/C++ connector interface.
I'd like to make a static library out of the existing code and am wondering how (or if it is possible) to link the MySql C/C++ interface with my static library seeing as there is no "Link" tab in the properties dialog of the project.
I'd basically like to link my static library to a new project and have everything work as it did in my old console application.
Is there a way of doing this (without simply just linking the MySql C/C++ interface to the new project) or am I looking at this from the wrong angle? If so let me know what might be a better alternative.
Static library projects (i.e. that output a .lib file on a win32 environment) haven't a link tab because they're not meant to be linked when generating the output file.
Instead they concur, alongside with other .lib files, to resolve link-time dependencies in a project (e.g. executable) that requires linking.
To do what you want you just need to include the necessary headers and make sure both your code and the C/C++ interface (which is also a lib file) are provided at link-time for the project that will use them and will be ultimately linked
Related
I have a executable project, Game.exe, which is linking against a library Engine.lib. I want to link another internal library, Video.lib, into Engine.lib, so that Game.exe can simply link against Engine.lib and not worry about the symbols provided by Video.lib. This sort of linking setup makes the most sense for my current solution.
In the librarian tab of Engine.lib, I have included the path of Video.lib as well as the file "Video.lib" in the input section. This works perfectly and I have access to the Video.lib symbols.
My issue is when trying to link against Engine.lib from Game.exe. I am not sure if I changed some sort of setting in the Game.exe project, but when I try build Game.exe, I get a linking error that Video.lib cannot be found. How is this possible, when I do not have "Video.lib" under the inputs of Game.exe?
Adding the path of the Video.lib file (simply the path, not the file itself) to the Game.exe project solves this, but obviously the whole point of this setup is that Video.lib should be merged into Engine.lib so that I only have to link Game.exe against Engine.lib.
Is there a setting in Engine.lib I have to set that specifies all Video.lib symbols should be pulled into Engine.lib, instead of making it a dependency for future projects that link against Engine.lib? Or have I set something incorrectly in the Game.exe project?
I do not want to use Visual Studio's "project dependencies" or "references" system.
Thanks!
Edit: This post here (Linking static libraries to other static libraries) does not answer my question, as it is both outdated (doesn't really contain information about the new VS interface) and doesn't answer the issue I am having (why is Game.exe trying to link against Video.lib). Since my question is about this problem and the other question is simply a "how to" I therefore do not believe my question is a duplicate.
Edit 2: I am certain that Video.lib IS being linked into Engine.lib due to the noticeable increase in file size. What I don't understand is why Game.exe still complains about not being able to find Video.lib
The issue turned out to be with the library I was using specifically, which is wxWidgets (I simplified the example above in order to avoid complications).
wxWidgets uses #pragma comments to link specific libraries in. In this case, wxWidgets ("Video.lib") was causing Game.exe to "see" these pragma comments and ultimately attempt to link in the libraries.
Adding all the wxWidgets libraries ("Video.lib") to "Ignore Specific Default Libraries" under Linker -> Input in Game.exe solved the problem to me, as this ultimately overrode the pragma directives.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
TL/DR: Question start with steps that I've made and that I think are important to mention (let me know if it is not important and I will delete it). The question itself is in the bottom of page. I've posted 3 questions that has the same steps that I've issued before asking the question, however questions are different. Thanks
I've successfully compiled libharu library with cmake so I can use it in my own c++ project to generate PDF files. It was compiled with Visual Studio 2013 as Debug/Win32. cmake-gui was set following way:
Sources:
c:\Users\wakatana\Downloads\__c++_pdf__generation\libharu-RELEASE_2_3_0
Build:
C:\Users\wakatana\Downloads\__c++_pdf__generation\libharu-build32
My current project (created from scratch) that I'm using libharu in has following structure (again Visual Studio 2013):
./Debug
./libharu_example
./libharu_example/Debug
./libharu_example/Debug/libharu_example.tlog
./libharu_example/libharu
./libharu_example/libharu/include
./libharu_example/libharu/lib
./libharu_example/libharu/src
./libharu_example/libharu/src/CMakeFiles
libharu/include contains files from C:\Users\wakatana\Downloads\__c++_pdf__generation\libharu-RELEASE_2_3_0\include
libharu/src contains files from C:\Users\wakatana\Downloads\__c++_pdf__generation\libharu-RELEASE_2_3_0\src
libharu/lib contains files from C:\Users\wakatana\Downloads\__c++_pdf__generation\libharu-build32\src\Debug
Visual studio project settings are following:
# C/C++ -> General -> Additional Include Directories:
$(ProjectDir)libharu\include
# C/C++ -> Preprocessor -> Preprocessor Definitions:
_CRT_SECURE_NO_WARNINGS
# Linker -> General -> Additional Library Directories
$(ProjectDir)libharu\lib
# Linker -> Input -> Additional Dependencies
libhpdfd.lib
Inside main file I'm including libharu this way:
#include "libharu/include/hpdf.h"
Finally to the question:
In the C:\Users\wakatana\Downloads\__c++_pdf__generation\libharu-build32\src\Debug directory there are also those files:
libhpdfd.dll
libhpdfd.exp
libhpdfd.ilk
libhpdfd.lib
libhpdfd.pdb
libhpdfsd.lib
I've tried to set Linker -> Input -> Additional Dependencies also to libhpdfsd.lib and libhpdfd.dll but the only one that worked was libhpdfd.lib. What is purpose of other above mentioned files and how do I know which *.lib *.dll should I use? Also why I need to specify this to Visual Studio? Isn't it smart enough that it can load it automatically? It has already specified $(ProjectDir)libharu\lib where all those libs were stored, why not just pick the best one automatically?
libhpdfsd.lib - this is a static library. Static libraries are linked at build time by the linker.
libhpdfd.dll - this is a dynamically linked library. In contrast to a static library, it is not linked at build time. Instead, it is loaded into process memory explicitly at runtime with LoadLibrary and addresses of its exported functions and variables are obtained with GetProcAddress. This requires writing some boilerplate code. To avoid doing that, there's often a corresponding static library, called import library, that automagically does this for you. This is what libhpdfd.lib is.
libhpdfd.pdb - this is a program database file. It is used by a debugger.
libhpdfd.exp - this is an export file. It is useful when you have cyclic dependencies.
libhpdfd.ilk - this file is for incremental linking. Incremental linking speeds up linking phase which is useful when during debugging you make small changes in your code and rebuild all project.
You need to specify explicitly a library you use because you may have different libraries or different versions of the same library, which export symbols with the same name. In that case a linker can't know from which library your symbol should be imported and you'd get a linker error. I believe the error you got when you added libhpdfsd.lib to additional dependencies was because of this.
Whether to use the static library or the dll is up to you. Your default choice is to use the static library, use dll when you have to.
In visual studio there are two types of lib files, first one is static library and second lib contains only symbols for mapping with a DLL. If you choose to build you project using dynamic libraries, VS will expect that the second type of lib is specified as it cannot distinguish the two from the filename and vice versa for building statically linked projects.
This question already has answers here:
What are *-devel packages?
(2 answers)
Closed 6 years ago.
I'm confused about the use for "*-devel" packages, and so I looked it up. According to an answer in this post, What are *-devel packages?:
"For running an application using the library libfoo only the actualy
shared library file (.so., for example libfoo.so.1.0) are needed
(plus possibly some data files and some version-specific symlinks).
When you actually want to compile a C application that uses that
library you'll need the header files (.h, for example foo.h) that
describe the interface of that application as well as a version-less
symlink to the shared library (.so, for example libfoo.so ->
libfoo.so.1.0). Those are usually bundled in the *-devel packages."
This seems redundant to me. To me it sounds like this: "To use the library you need just the libfoo. But if you want to use the library, you need the header files and hence libfoo-devel"
I can't quite find the answer to the importance of the header files.
After you built an application using libfoo, you obviously do not need any of libfoo's headers installed any more. The application is already compiled. You don't need the header files to run something that's already compiled. The only thing you need is libfoo itself, because your application is linked to it.
And that's your libfoo: just the library itself. Maybe an occasional configuration file, or something else, that's needed at runtime.
On the other hand, if you need to build and compile the source code that uses libfoo, you need the header files, and other supporting files. Whatever is needed to build the source code that uses libfoo.
And those bits are the ones that go into the libfoo-devel package. That's the stuff that's needed to build the source code that uses libfoo.
I have a C++ project and I am linking to an external library (using all of its headers and source files). I did this by going into the project configuration and adding the source.a library that i wanted to link to. Now my question is how do I know if my library is linked to my program statically or dynamically. I have read numerous thread about the types of linking however i am still not sure about the type of linking I have. Any suggestions on this regard would be helpful
I did this by going into the project configuration and adding the source.a library...
It's static. If it were dynamic you would have added a .dylib file instead (which apparently you don't have one of).
This question already has answers here:
Copying a DLL's dependencies in Visual Studio
(9 answers)
Closed 8 years ago.
I downloaded a source code form a website and it contains the main.cpp and a folder with some .dll files. In the main.cpp file there are includes to headers with similar names to the .dll files. Is there any way I can use the source code in a VS project with only the .dll files even if I have not the headers?
To answer your question, yes you can do that. Just load a DLL using the LoadLibrary() function and resolve functions from it with GetProcAddress(), aka "explicit loading". However, this requires knowledge of the interface that the DLL exports, which is equivalent to the information provided by the headers that you don't have. If you had the information, you could also write the headers, if you don't, you can't load the DLL. Note that to some extent, tools like dependencywalker can determine the DLL's interface, but that may or may not be enough to use it. In summary, no, you can't do that, you need to know the interface.