I was just wondering what my options were for cross-platform implementations for the dynamic loading of plugins using shared libraries. So far the only one that I have found is:
http://library.gnome.org/devel/glib/stable/glib-Dynamic-Loading-of-Modules.html
And I was just wondering if I had other options? Essentially, I want to be able to put plugins in shared object files, and load them at runtime and I wanted to do it in a cross-platform C++ way.
Edit: I found this Dr Dobbs Post from 2007; surely somebody has come up with something more since then.
You could look into Boost Extension, though it has not yet been accepted into Boost.
The Boost.Extension library has been
developed to ease the development of
plugins and similar extensions to
software using shared libraries.
Classes, functions and data can be
made available from shared libraries
and loaded by the application.
Qt has a nice plugin system. You should take a look at the second part of that page.
If you want something simple and lightweight try: https://pocoproject.org/docs/package-Foundation.SharedLibrary.html
Using the SharedLibrary class it takes three lines to call a function in a C shared library:
Poco::SharedLibrary lib("libfoo.so");
int (* foo)(int) = reinterpret_cast<int (*)(int)>(lib.getSymbol("foo"));
printf("answer %d\n", foo(5));
Related
I am in the need to link against a library (written in Qt by myself). Of course this would generate (regardless of the extern "C" and name mangling stuff) a lot of errors during linking because of the C++ dependencies (stdc++ and Qt).
So I have got an idea, but I'm not sure, if I am missing something or if the approach is a realistic solution at all:
Searching some hints on this topic, I have found an article about building static Qt. Without reading all of it in detail I think the solution could be to compile Qt statically and then link my application against this static version of Qt. In my opinion this should lead to a successful build because of the following reasons:
Building my Qt library with the static Qt Library (again as static lib) would resolve all dependencies because they are all in the static lib archive.
Because of the extern "C"d interface functions, that will be accessed by the c application the C compiler (and linker) will also see all dependencies resolved and here is no problem either.
Now before trying the exhausting steps to build Qt statically, I would like to know, whether this approach could solve the problem.
EDIT 1:
The alternative solution would be to implement a server-client architecture on top of both the Qt- and the C-part of the application and let them communicate in that way with each other.
EDIT 2:
The probably best solution is neither of the both mentioned. Instead I just wrote a dynamically linked boundary (as suggested by Laszlo Papp and dsu) and everything works fine.
Now before trying the exhausting steps to build Qt statically, I would like to know, whether this approach could solve the problem.
Based on the comments where you mention that becoming a commercial client of Digia is a problem, I would say no.
Static linking cannot happen with proprietary software, and based on your comment, your project is not open sourceable.
That being said, you seem to have your own wrapper anyway, and Qt keeps binary compatibility for a given major version the lifecycle of which is usually several years, so I would personally go for dynamic linking and some kind of binding.
I've created a simple FTP server in C++ using Sockets, and as a part of the project I need to port over some of my code into a library. Basically I'll be wrapping some of the native Socket functions and utilizing them in library form.
The library has to be compatible with 32 and 64 bit systems, compile into either static or DLL form, and also work for debug and release mode. Our professor went over this process over the course of three hours in class, but obviously much of the process was lost on us, and it's not written down anywhere.. so I'm hoping to find a good reference on the subject that can help me do this correctly.
Read the program library howto. It explains quite well. Read also ar(1)
I am not sure you should make a static library (eg some libfoo.a). Dynamically linked i.e. shared libraries (e.g. libfoo.so) are generally preferable. Read Drepper's paper: How to write shared libraries
Look also inside libcurl source code. It should teach you a lot.
GNU make knows about archive files, i.e. static libfoo.a libraries.
I've heard a lot of good comments about Boost in the past and thought I would give it a try. So I downloaded all the required packages from the package manager in Ubuntu 9.04. Now I'm having trouble finding out how to actually use the darn libraries.
Does anyone know of a good tutorial on Boost that goes all the way from Hello World to Advanced Topics, and also covers how to compile programs using g++ on ubuntu?
Agreed; the boost website has good tutorials for the most part, broken down by sub-library.
As for compiling, a good 80% of the library implementation is defined in the header files, making compiling trivial. for example, if you wanted to use shared_ptr's, you'd just add
#include <boost/shared_ptr.hpp>
and compile as you normally would. No need to add library paths to your g++ command, or specify -llibboost. As long as the boost directory is in your include path, you're all set.
From the boost documentation:
The only libraries that need to be compiled and linked are the following:The only Boost libraries that must be built separately are:
Boost.Filesystem
Boost.IOStreams
Boost.ProgramOptions
Boost.Python (see the Boost.Python build documentation before building and installing it)
Boost.Regex
Boost.Serialization
Boost.Signals
Boost.Thread
Boost.Wave
A few libraries have optional separately-compiled binaries:
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.
Boost.Graph also has a binary component that is only needed if you intend to parse GraphViz files.
Boost.Test can be used in “header-only” or “separately compiled” mode, although separate compilation is recommended for serious use.
So, if you're using one of the listed libraries, use the Getting Started guide to, well, get you started on compiling and linking to Boost.
The Boost website has some good tutorials, they are just kind of hidden.
The library documentation is a mixed bag. Some is good, but some is more of a reference than a guide. The best guide to (some of) the Boost libraries is the book Beyond the C++ Standard Library. At the very least, the introduction gives one paragraph descriptions of many of the libraries. From there, you can decide which library is most important for your current needs, and, if it's in the book, read the chapter on it, or read the documentation on the website.
If you read German, there's a good online guide. Google translate does a good enough job that a non-speaker like me can understand it.
Also, unless you have lots of experience with C++, I'd start with the simpler libraries (e.g. smart_ptr, tuple, conversion, tokenizer, regex, date_time, test), before trying the more complicated ones (bind, variant, any), or the really advanced ones (concepts, MPL, Fusion).
Using Easypeasy 1.1 (for netbooks) which is based upon Ubuntu I was able to use Synaptic Package Manager to install, I believe, libboost-dev. Then simply by adding:
#include "boost/foreach.hpp"
I was able to replace the existing lines in an existing application (which has an Ask class which has nothing to do with boost):
for (std::vector<Ask*>::iterator ii=ui.begin(); ii!=ui.end(); ++ii)
std::cout << (*ii)->prompt() << (*ii)->answer() << std::endl;
with:
BOOST_FOREACH (Ask* ii, ui)
std::cout << ii->prompt() << ii->answer() << std::endl;
As I understand it this is a header only feature. I have not used anything requiring link time changes yet.
I was just looking at that german boost guide, and found there was an english one as well (same book). It looks pretty good, have just read the introductory pages which are quite useful
The best tutorial I've read so far are those two books:
Introduction to the Boost C++ Libraries; Volume I - Foundations
Introduction to the Boost C++ Libraries; Volume II - Advanced Libraries
The libraries come with documentation and many of them have tutorials as part of the documentation. Just start reading.
Boost is not a programming language nor an application framework - because it's just a collection of libraries, there is no such thing as a Boost 'Hello World' program. Most libraries in Boost can be used more or less independently, and they vary in size from one function to massive libraries that could stand alone.
The best way to get to know Boost is simply to try and work it in as you write new code. Use smart_ptr whenever you can; use the MPL next time you want to do compile-time work. There's a lot of variety in Boost, but you should probably start looking at the Utility section; those are the lightest-weight and most commonly-used libraries.
When developing a C/C++ (=2?) plugin based framework with shared objects/dynamic libraries that need to support live swapping what examples would be helpful to look at for implementation details?
Thanks.
Note: live swapping is the key point here, no need to restart the system is a requirement
If you are on POSIX, dlopen(), dlsym() and dlclose() are all you need.
See man dlsym for details and examples.
There is a good article about loading dynamic libraries, and plugin infrastructure is an example.
EDIT OP added Windows as requirement so this approach won't help since Windows isn't POSIX-compliant. However there are similar functions in WinAPI - see here.
You might want to try Boost.Extension but beware : despite its name, it is not one of boost libraries.
Here is a link to its documentation.
For C++ plugins you can check this article which detail how to achieve it with the previously mentionned posix calls.
Quoting the article :
Given that we can use these functions to access functions in a C library, how do we use them to access classes in a C++ library? There are several problems to overcome. One is that we must be able to locate the symbols we need in the library. This is trickier than it might seem because of the difference between the way symbols are stored in C and C++ files.
If you want cross-platform library loading without having to develop for each platform's API individually, libltdl may help.
Libtool provides a small library, called libltdl, that aims at hiding the various difficulties of dlopening libraries from programmers. It consists of a few headers and small C source files that can be distributed with applications that need dlopening functionality. On some platforms, whose dynamic linkers are too limited for a simple implementation of libltdl services, it requires GNU DLD, or it will only emulate dynamic linking with libtool's dlpreopening mechanism.
libltdl supports currently the following dynamic linking mechanisms:
dlopen (Solaris, Linux and various BSD flavors)
shl_load (HP-UX)
LoadLibrary (Win16 and Win32)
load_add_on (BeOS)
NSAddImage or NSLinkModule (Darwin and Mac OS X)
GNU DLD (emulates dynamic linking for static libraries)
libtool's dlpreopen (see see Dlpreopening)
Boost.Extension seems to only support Windows PE dlls, UNIX ELF shared objects, and Mac OS X Mach-O bundles. Well, that may be sufficient for you...
Boost.Extension seems nice (never used it but will try soon). Another alternative would be the POCO SharedLibrary class.
I recently had to program C++ under Windows for an University project, and I'm pretty confused about static and dynamic libraries system, what the compiler needs, what the linker needs, how to build a library ... is there any good document about this out there? I'm pretty confused about the *nix library system as well (so, dylibs, the ar tool, how to compile them ...), can you point a review document about the current library techniques on the various architectures?
Note: due to my poor knowledge this message could contain wrong concepts, feel free to edit it.
Thank you
Feel free to add more reference, I will add them to the summary.
References
Since most of you posted *nix or Windows specific references I will summarize here the best ones, I will mark as accepted answer the Wikipedia one, because is a good start point (and has references inside too) to get introduced to this stuff.
Program Library Howto (Unix)
Dynamic-Link Libraries (from MSDN) (Windows)
DLL Information (StackOverflow) (Windows)
Programming in C (Unix)
An Overview of Compiling and Linking (Windows)
Start with Wikipedia - plenty of information there, and lots of links to other useful resources.
P.S. But perhaps it would be better to just ask a specific question about the problem you're currently having. Learning how to solve it may go a long way to teaching you the general concepts.
You can find some background information from this article here. It gives you the basic background. I'm trying to locate something with diagrams. This should be a good place to get started.
The fundamental differences between a static library and a DLL is that with the static library the code is compiled into your final executable whereas a dynamic link library involves linking in a "stub" library (into your application) which contains mappings to functions in a separate file (.dll).
Here's an MSDN entry on creating a static Win32 Library which might also help you.
..another link to MSDN for creating a Dynamic Link Library..
Just found this site which covers definitions of basically all the aspect you've quoted.
There is always MSDN for windows related stuff:
Head page for dlls ->
http://msdn.microsoft.com/en-us/library/ms682589
For Unix my favorite reference manual:
Programming in C, UNIX System Calls and Subroutines using C ->
http://www.cs.cf.ac.uk/Dave/C/
RM
See if these are useful:
Static and dynamic libraries
Program Library HOWTO