I'm using the ASIO libraries to make a udp sending wrapper. The intent is for this to be used by another app to easily send 3 specific udp messages.
I've created a .lib file which is basically an exported utility class that wraps the ASIO functions.
To test my lib I also made a little command line app which links to my lib, creates the exported class and calls the send function.
However, the test application is requiring to link to libboost_system-vc100-mt-gd-1_55.lib but the lib file I created which actually contains the Boost code does not.
Why is this happening and how can I fix this?
A .lib file, static library, is just a grouping of object files, it's not an executable entity. It isn't linked thus it doesn't require it's unresolved symbols to be resolved.
Only the executable or shared library (DLL) that link with it need the dependencies (in this case your test code).
So there's no problem, perhaps you meant to bundle your library as a shared library rather than a static library?
Most of the boost libraries rely on boost::system because of the exception/error management is used.
boost::asio definitely uses that.
A test runner application needs to link everything as it's going to be a (statically or dynamically linked) executable, and all of the references need to be resolved.
The Boost::Asio library is available (from the same author) as a header-only standalone version.
See his think-async.com website for details, and comparison. The standalone version is useful when you do not need (or want) to have a link-time depedency on Boost. More details are on the AsioStandalone page.
FWIW I bundled this for use by R programmers as CRAN package AsioHeaders because the 'no linking' feature makes the cross-platform use particularly appealing.
You could similarly provide header-only solution for your application.
Related
I'm building a shared library that is loaded from an application (which I have no control of). My library uses other shared libraries which in turn uses other shared libraries, complex but not unusual.
The problem is that the main application have functions present in one of the libraries further down in the chain, to be more specific it is openLDAP that in turn uses openSSL functions:
Main app->My library->openLDAP libraries->openSSL libraries
My guess is that the main application is implementing openSSL either by a static linkage or a simple copy/paste of source code.
My question is: can I control which functions openLDAP uses from my library or do I have to recompile openLDAP with a static linkage to openSSL?
Since openSSL is updated quite frequently due to security issues I don't want a static copy of it if I don't have to. And why re-distribute a proprietary copy of openLDAP when it's part of most distributions packages...
Right now what you have is the executable overriding what would otherwise be the system's default choice of OpenSSL library. It is within the executable's rights to do that, and you can't really stop it.
Statically linking OpenSSL in your library may not really be a solution either. For one thing, what if the executable really does was to use a different version? For another, what if OpenSSL has some global variables? Now you will have two copies of the library in the same process, which is not a good idea and may cause bugs.
To me, the best answer we have on Linux is to not consider this sort of thing to be a problem. If an executable loads a bad version of OpenSSL, that is not your library's fault. At most you can check which version is loaded and refuse to run if it's known to be incompatible with your library for some reason.
My guess is that the main application is implementing openSSL either
by a static linkage or a simple copy/paste of source code.
This is wrong things. If application developer shoots on his foot then you can not do anythings.
App developer should see that your library is dependent on OpenSSL library (using ldd command) then he should not link OpenSSL again as staticly or copy paste its code.
If some functions from OpenSSL does not creating any messy and if they can be used just like any static method of any java class then only App developer should take risk of implementing that code in app.
The solution was to use RTLD_DEEPBIND in dlopen(3):
RTLD_DEEPBIND (since glibc 2.3.4)
Place the lookup scope of the symbols in this library ahead of the
global scope. This means that a self-contained library will use its
own symbols in preference to global symbols with the same name
contained in libraries that have already been loaded. This flag is not
specified in POSIX.1-2001.
This might not be the the best solution but it works in this case when the process is created by closed source software.
I am currently making a small library of reusable code out of what has proven useful over the time and I'm wondering how are libraries usually deployed? I was under the impression that a .dll and .lib would be enough, but then, how do i reference the classes and functions? Is it common for a library to also come with a lot of .h files or there is a more elegant solution?
What about deployment of the actual application that uses the library? Once linked statically do I also need to send the .dll file or the content of the library is copied in the program?
As a rule of thumb, you gather all your public methods, which you want to expose to end users, in a group of headers called API. At this point, you should make a distinction between internal headers and API headers and you will see that your header file number (API headers) will decrease and management of file structure will be a lot easier.
There are three essential components when you deliver a library:
several versions the library itself: .so under Unix, .dll and .lib under Windows, with versions for debugging, optimized versions, possibly multithreaded and single threaded, possibly a version with profiling activated... and support for static linking (.a under Unix, .lib under Windows, but not the same one as you need to link the DLL),
the headers which define your external interface, and
the documentation, explaining how to install and link the libraries, which compiler options are required for each version, etc. as well as the documentation of the library itself (pre- and post-conditions for every function, etc.)
Anything less, and the client won't be able to use it.
Regarding deployment, again, this should be documented. If the client links the library statically, then nothing should be required; if he links it dynamically, then he will need to deploy the .so/.dll files as well.
I've got a huge application here called HugeApp, it needs different libraries (which I've coded) and some of these libraries might need dependencies (other libs coming from the internet or ad hoc lib developped here).
I was wondering, if it was feasible and/or a good idea to hide some of these dependencies from HugeApp.
Let's say that you make a library in charge of doing the encrypted communication on a system, does the top application care and/or needs to know that there is some encryption libraries that are needed for this part (comms) of the system? It might be implementation specific... or not...
Thank you
There's no need for it to know, if you build those libraries as external DLL's then the external libraries are the only thing that care about the dependency. If you add a reference to the pre-built DLL then HugeApp doesn't need to know about the dependencies of the library (as long as they are either present in the library or the appropriate DLL or lib file is present so that your dll can make use of it). If anything your library can be another project altogether and you can include a reference to that in which case the project of your HugeApp only cares about that main reference and the other project will handle everything else.
If you enable /OPT:REF in linker optimizations it you will list which (if any) libraries that have no functions or data used by the project during link time. You can then remove them from the dependency list and link line in project settings. This will reduce the chance of removing a static library that is a dependency of another static library if any are present/used in your VS solution.
I'm using a closed source library (by Activ financial) that includes with their API a boost distribution, both some boost header files and boost library files.
I also use Boost in my existing codebase, and I need to use Activ from my existing code.
Some points
I can encapsulate my use of Activ so that the entire Activ part amounts to a single class I wrote that does not expose any of Activ's headers
This single header file does not use any boost anything
In this way I can ensure that the Activ parts of my code use Activ's Boost HPP files, and my code uses my Boost's HPP files
My worry comes in linking. How can I ensure that my Activ dependent code links to Activ's Boost, and my other code links to my Boost?
I'm using g++ now, will also be doing this in VS2008. I got it working in VS2008 before, but I have no idea how everything linked. I want to try to make sure it's done correctly.
Is there a way to do it without further encapsulating the Activ part in a dynamic library?
Edit:
For one, my final product is always an executable file. For two, I statically link to boost myself. The Activ library includes both static and dynamic versions of Boost object libraries, and I plan to statically link it.
I never pass Boost objects between code that uses different boost versions.
The question is, how do I link one cpp or .o file to objects in one library file, and then make sure other .o files link to the identical objects in another library file? Is this possible?
Does the library dynamically or statically link to Boost? If statically linked, does the library expose the symbols in the DLL (declspec export)?
If the library is statically linked and the symbols are not exposed, and you do not pass any Boost data structures (smart_ptr, threads, etc) back and forth, you are likely safe to use your own version of the Boost library in your DLL.
I have a framework (in C++) which is dependent on a few third party libraries. When I compile a static version of the library framework, no additional dependencies are needed, that is, the lib files of the third part libraries are not needed. When I compile the same framework as a DLL, additional dependencies are now needed otherwise I get linking errors. I can guess as to why this is happening but would like a concrete answer/explanation to understand what is happening.
EDIT: Just to clarify, I am developing a framework which can be compiled as a lib and as a dll and then used in a(n) (executable) project. When compiling the framework as a lib and using functions from a third party library, I don't need additional dependencies. However, a project that now uses the lib file (which is the framework) must include the 3rd party lib files. When I compile the framework as a dll it gives me linking errors unless I specify the 3rd part libraries the framework is technically dependent on. For example: I have a few classes that call functionality from within Ogre3D. These classes are compiled as a lib file. I don't need to link against OgreMain.lib when compiling a lib of the classes. On the other hand, when I am compiling a dll version of the same classes, I now need to link against OgreMain.lib
When you have a static library (a .lib file), which is just a collection of one or more object files (.obj), the linker just adds that code to yours in one executable. You can tell the linker to do this via a command line switch, an IDE configuration setting, or perhaps even a #pragma (specifics depend on your environment and compiler).
When you link in a DLL, you need to give the linker some code to call when you invoke one of the DLLs functions. Usually, this is done with a file of the same name as the .dll, save that it is a .lib. The code in that .lib is linked into your program the same way as described above, but when you call it, it loads the DLL (if not already loaded) and then invokes the proper function.
There are other ways to handle DLL linking (for instance, .def files or #using statements in .NET), but this seems to be what you're talking about.
Responding to your question clarification:
The issue is that a .lib is not a final product. It is just an aggregation of object code to be used later when a linker connects all your functions calls to function addresses.
A DLL, on the other hand, is a final product, and so the linker requires all functions and variables be connected to actual addresses.
I'm speaking a bit imprecisely, but you get the idea.
A static library can include other static libraries, providing a single lib to link
A DLL can include static libraries, providing a single DLL to link.
A DLL or static library with dependencies on other DLLs has no way to combine them so your executable must explicitly link to those other DLLs.
When you link to a LIB it adds all the symbols/functions you actually use to your executable. The ones you don't use won't get added. When you link to a dll - all the code from the external library gets loaded. If this additional code (code you don't use) depends on more external libraries you need to provide these as well.
One example: You want to use a ip class from a network library. The ip class does not depend on other libraries. Other functions in the network library depend on other external libraries. If you link the network library as a LIB you just link the ip class -> you don't need the other libraries since the other code wont get linked. When you use the DLL all code in the dll need to be instanciated -> so you will need to provide the other external libraries.
Building a DLL is more like building an application than a library. The difference between building an application and a DLL is knowledge of what might be called. In an application all symbols that are not used can be discarded in the build, but in a DLL you cannot strip symbols that are not used - that would be all of them...
You would find the same link problems in your static libraries if you where able to call all the symbols that the DLL links.