I've compiled Boost and it works just fine. I would like to to copy specific .dll's and .libs into my project for deployment. The problem is I'm having a hard time finding which packages contain the libraries I need. I've looked around but haven't seen any documentation on what's actually inside the compiled libraries.
For instance, if I wanted to use boost:asio and boost::prt_vector in my project, which .dll/.libs should I copy over?
The entire library folder is over 1.2 GB so I'd rather not use the entire thing. I'm using Windows, vs2008.
Any ideas?
Are you deploying your application as an executable or as a project to be compiled by the user? If it is the former, you shouldn't need to send static libraries, as they're linked into your executable. If you build Boost libraries as dynamic libraries, you will need them of course.
But if you're deploying your app as something to be compiled, or if you have Boost DLLs, then as martiall said, you should use BCP.
You can use the bcp which is bundled in Boost
BCP Docs
Related
one thing I haven't been able to work out running with bazel is using libstd dynamically
that is, using
libstdc++-6.dll
I have to manually copy this into the bazel-bin in order to use it. I was hoping this would be something I can have bazel manage such that it will do this each time automatically (on a full project clean for example)
I am able to have it work by specifying linkopts=["-static"] to statically link against the standard library, however this is not ideal, since sometimes I might be using a 3rd party library whose built files might require the DLL.
Any help here would be massively appreciated, thanks
I'm starting to look into deploying a Qt application I've been developing but I've never had to deploy any C++ application before this.
I want to be able to ship my product as a pre-compiled executable that dynamically links against shared library files(Qt) for Linux/Windows so that there is an executable that looks in its own sub directories for libraries instead of libraries that may be installed as a result of other Qt products.
Is this something that is possible? Or must the Qt library files be installed separately for an application to link against them? I want to avoid requiring the end user to install ANYTHING on their systems while also avoiding static linking.
This is a normal behavior for Qt. How to do it greatly depends on your build system.
If you use CMake, you can generate installers with CPack. Here is a link to adding the required shared libraries to an installer. CPack makes many different types of installers for Linux, Windows, and Mac OS X.
You can also generate your own installers using NSIS. This is a lot more involved but doable.
Qt has documentation on how to deploy applications that use their libraries.
At my company, we do both CPack and NSIS. The CPack way is a lot easier and there is more examples online.
I got a VS10 project. I want to build some C++ code so I can use it in python. I followed the boost tutorial and got it working. However VS keeps to link boost-python-vc100-mt-gd-1_44.lib but it's just a wrapper which calls boost-python-vc100-mt-gd-1_44.dll. That's why I need to copy the .dll with my .dll(.pyd) file. So I want to link boost:python statically to that .dll(.pyd) file. But I just can't find any configuration option in VS or in the compiler and linker manual. The weirdest thing is I've got one older project using boost::filesystem with the very same config but that project links against libboost-filesystem-*.lib which is static lib so it's ok. I've been googling for couple of hours without any success and it drivers me crazy.
Thanks for any help or suggestion.
You probably don't want to do that. Statically linked Boost python has a number of problems and quirks when there are more then one boost python based library imported. "But I only have one" you say. Can you guarantee that your users won't have another? That you might want to use another in the future? Stick with the DLL. Distributing another DLL is really not that big a deal. Just put it side-by-side in the same directory.
What libraries are linked depends on the settings of your project. There are two possibilities: You can build against
statically
dynamically
linked versions of the c-runtime libs. Depending on which option is selected, the boost sends a proper #pragma to the linker. These options need to be set consistently in all projects which constitute your program. So go to "properties -> c++ -> code generation" (or similar, I am just guessing, don't have VS up and running right now) and be sure that the right option is set (consistently). Of course, you must have compiled boost libraries in required format before...
I'm quite new to using boost and I can't seem to find documentation anywhere on how to distribute your application when using boost?
Many of the libraries are shared libraries, I'm not expecting my users to have boost installed, I'm only using a single library (regex) so is there an easy way to package the regex library with my application without compiling with the static version?
Linux
For binary distribution, I recommend using the distribution's package management, which should take care of any dependencies.
Some commercial apps just use binary blobs and you need to install a version of boost by yourself.
Finding libraries is a bit more difficult on linux. It does not automatically load shared objects from the current directory if they are linked at compile time (as opposed to loading at runtime with dlopen).
You have to use the LD_LIBRARY_PATH env variable or use rpath. Both has it's drawbacks.
Windows
There is no way around including the dlls. The usual approach is to put everything into a directory and zip it up.
Both
To build from source you need the boost sources anyway, so no need to include libraries.
Most libraries in boost are header only anyway, regexp is not one of them. It should be sufficient to include dlls for this module.
In Linux you can check against which shared libs your binary is compiled by using:
ldd binary
Whenever we specify -lxerces-c, this looks for libxerces-c.so library in the LIBPATH.
Q1. Why are lib files then generated as libxerces-c.so.28?
Q2. How should we link against such libraries?
The only way I can think of is create a soft link libxerces-c.so which links to the file libxerces-c.so.28. I feel this as an overhead to do. Is there any other way around which is better?
The file name has a version number so that you can have one program that uses version 2.8 and a different program that uses version 2.9. This way, adding a new version of the library will not change the behavior of existing programs that use an old library.
Normally, there should also be a file libxerces-c.so which is a sym link to the version of the library you want your newly built programs to use.
Many Unix package managers will have a separate development package that installs the symlink. It sounds like you don't have the devel package installed.
There's one more reason to it: when linking to libxerces-c you also probably include some xerces header files in your program. And those headers are tied latest version of binary library (through libxerces-c.so symlink).
Meaning that if you compile with headers from xerces-2.8 and link libxerces-2.9 library binaries there's a great chance it will not work out.
Think of it as a precaution from mixing headers and binary libraries.