I am trying to embed the boost uuid package in my project. For ease we would like to just include some DLLs, as we do with most libraries we use. I can't figure out how to get just the DLLs for the uuid package (and any necessary dependencies). I have tried building normally, b2, bcp, and anything else I can find but all I get are copies of the source or DLLs for many of the libraries but not uuid, which is the only one I need.
In case it makes a difference, this is for a windows application. We have lots of different developers with different environments and would really just like something (like a DLL but I'm open to other options) that we can include in our source control so everyone doesn't have to install boost and set it up the same way. Ideally we would also like just boost/uuid and any dependencies, not the whole gigantic library.
Boost uuid, like many boost libraries, is header-only: you can't find any dll because there is no dll for this library. Just copy and include the headers where you need them.
See the documentation.
BCP can be used to extract uuid and its dependencies.
Related
I'm an amateur in programming. I was wondering how I can use boost's serialization only (https://www.boost.org/doc/libs/1_36_0/libs/serialization/doc/index.html).
When I download boost, it has many libraries and is a big folder, but I just want to use the serialization library. Does my user need to install of all boost in order for me to use serialization?
I'm a complete beginner, so if you can tell me each step I need to do to get serialization into my project, it'll be much appreciated. For example, do I have to statically link a library? I have no idea. Thank you for your help.
edit: I want my user to not have to deal with much. So is there a way to use boost without having the user to install anything? Thank you.
You usually need to link the "link library" (traditionally a .lib file on windows) that matches the "dynamic library" (.dll) at runtime. Of course, at runtime it needs to exist, so you need it "installed" (present at the target machine, in a compatible form, so matching the OS and architecture).
The good news:
MSVC will do "Auto Link" for the lib (https://www.boost.org/doc/libs/1_68_0/more/getting_started/windows.html#auto-linking)
If you build on a platform similar to your target platform, the default target will usually be compatible with the target
Note that you may need indirect requirements (such as Boost System).
Indeed, you can XCOPY-deploy the libraries in the same folder as the exe file, but that's not really a common approach and might not be the best idea if you have little experience.
If you can get your hands on a (free) installer builder (a quick google leads to things like https://www.techrepublic.com/blog/five-apps/five-apps-for-creating-installation-packages/) you'll enjoy the guidance of tools that know the intricacies involved.
Does my user need to install of all boost in order for me to use
serialization?
When you link boost, the MSVC++ and MFC runtimes statically into your application, you get a single executable, that includes all dependencies. Then all your user has to do is double-click the .exe file of your application.
Building boost libs from scratch can be tricky, so for getting started I recommend to download prebuilt binaries. Make sure to download the package that exactly matches both your version of Visual C++ and the bitness (32/64) of the application you are building.
Though in the long run, it can be beneficial to build boost yourself, so you don't depend on the prebuilt binaries being up-to-date for the most recent version of VC++.
Make sure to add the directory path of the .lib files to your project's library path. You don't need to specify individual .lib files because boost uses auto-linking.
In case you need to know, the static lib files include "mt-s" in the file name (e. g. "libboost_serialization-vc141-mt-s-x32-1_68.lib" for the 32-bit release version and "libboost_serialization-vc141-mt-sgd-x32-1_68.lib" for the 32-bit debug version).
In your project settings, make sure to choose MFC static library ("Generic" category > "Use of MFC"). Also choose "Runtime Library" > "Multithreaded" (/MT) or "Multithreaded Debug" (/MTd), depending on your project configuration (C/C++ category). If you don't do this, the linking will fail or you will link to the boost DLLs instead.
I'm publishing a multi-platform library and it's working everywhere except Linux. There's probably a way to do what I need, but I'm not seeing it and hoping someone here can help.
My library consists of two projects, 'subLibrary.lib' and 'library.lib' on Windows (for example). I build 'subLibrary' then link it into 'library' for distribution. Consumers only have to link with 'library' to get everything, including what's in 'subLibrary'.
Every other platform works the same -- I publish one giant 'library.a' that contains everything and consumers link with it, not having to know about any of the lower-level dependencies.
When building a standard executable on Linux, my link command must specify not only 'library.a' but also every dependency of it. This is because intermediate libraries leave symbols unresolved until later.
What I want to do is make it the same as the other platforms so the consuming executable only has to link with 'library.a' and that library contains everything it needs.
I know this will make the library larger, but it's the only way to ensure dependency resolution and build time for everyone.
On unix a library is simply a collection of all the object files. You can add more files to the library with AR, but you do need to be careful of file name conflicts.
I am using C++ with Visual Studio 2008 Express.
We are supplying a binary-only Windows library to a client, which itself uses a number of other libraries. Therefore we shipped both our dll file, along with the dll files that we use. Now the issue is that our client uses some of the libraries that we also use, but in another version. Therefore he can not use our library, since the libraries we both depend on are incompatible.
Technically I think it should be possible that both dependency versions are loaded into the process space. However, I am unsure how to do this, as both their application, as well as our dll look for the same dependency dll file name. Can anyone tell me what the best/cleanest way to deal with this problem is?
Thanks!
Generally speaking, it won't work. This is due to the fact that the third party DLL versions might interfere with each other when loaded into memory. One example could be if there is an exclusive resource like e.g. a file in a specific directory. Or a specific device. The problem is, nobody knows probably not even the manufacturer of the 3rd party DLLs - so extensive testing is necessary.
But maybe you're lucky and it works anyway. My recipe:
Put your DLL "DTAG.DLL" and all needed DLLs in a subdirectory of the applications directory with a fixed name e.g. "DTAG_LIB".
Write a import library by hand (there are other possibilities using DELAYLOAD). In that library load your DLL with LoadLibraryEx. Provide an absolute path ending with "DTAG_LIB\DTAG.DLL" and the flag LOAD_WITH_ALTERED_SEARCH_PATH. Windows will then load your DTAG.DLL from this directory and all needed DLLs from that directory also. Don't set the PATH to "DTAG_LIB"!
Your customer has to link against your manual import lib.
You could solve this kind of problem using a (new) additional DLL you would deliver and that would take care of handling the versions conflict (at runtime) - being a kind of proxy between your app and its dependencies.
An alternative would be to use the Windows Forwarded Libraries mechanism.
Forwarders are a handy way to accommodate functionality moving from one DLL to another
You can use several ways to declare forwarders, such as a module definition (.def) file and a #pragma:
#pragma comment(linker, "/export:function=otherdll.function")
I'm not new in C++ although I'm new in Linux. I'm using CMake to precompile a cross-platform game engine with some third-party components, but I have a lot of doubts about using libraries. My question is how to work with third-party libraries and where to put them. Apt installs libs in their official place (/usr/local, /usr/lib/ ..) but I develop in Windows using local libs that are in a folder in my project dir.
Also, I need a good tutorial to know the rules of how libraries work. For example: when trying to compile my project, luabind is asking for liblua.s0.1, but AFAIK there is no way to generate this library with the source provided by Lua (at least doing make, make install).
I know, this question is fuzzy but I haven't enough experience to be more concise.
Update: After reading some answers, a more concise question is the following. If I install all third-party libraries, how can I distribute my program? How do I manage dependencies without using a large readme?
Where to put libraries
The best solution is to use your Linux distribution's packaging system (apt-get, yum, or similar) to install libraries from distro-provided packages wherever possible.
If the distro's packaged libraries aren't of a recent enough version, or if you need some nonstandard build options, or if you need a library that your distro doesn't provide, then you can build and install it yourself. You have two main options for where to put the library:
/usr/local (libraries under /usr/local/lib, headers under /usr/local/include). This installs the libraries systemwide and is probably the simplest solution, since you should then be able to build against them without taking any extra steps. Do NOT install libraries directly under /usr, since that will interfere with your distro's packaging system.
Under your project directory, as you did under Windows. This has the advantages of not requiring root access and not making systemwide changes, but you'll have to update your project's include paths and library paths, and you'll have to put any shared library files someplace where the dynamic linker can find them (using LD_LIBRARY_PATH or ld.so.conf - see the link for more details).
How libraries work
See David A. Wheeler's excellent Programming Library HOWTO. I'd recommend reading that then posting any specific questions as new topics.
How to distribute your program
Traditionally, Unix / Linux programs do not include copies of their dependencies. It's instead up to the end user or developer to install those dependencies themselves. This can require a "large README," as you said, but it has a few advantages:
Development libraries can be installed, managed, and updated via the distro's package manager, instead of each source copy having its own set of libraries to track.
There's only one copy of any given library on a system, so there's only one place that needs updating if, for example, a security flaw is found. (For example, consider the chaos that resulted when zlib, a very widely used compression library, was found to have a security flaw, so every application that included an affected version needed to be updated.)
If your program is popular enough (and is open source or at least freely available), then package maintainers for various Linux distributions may want to package it and include it in their distro. Package maintainers really don't like bundled libraries. See, for example, Fedora's page on the topic.
If you're distributing your program to end users, you may want to consider offering a package (.dpkg or .rpm) that they could simply download and install without having to use source. Ideally, from the end user's perspective, the package would be added to distros' repositories (if it's open source or at least freely available) so that users can download it using their package managers (apt-get or yum). This can all get complicated, because of the large number of Linux distros out there, but a Debian/Ubuntu compatible .dpkg and a Red Hat/CentOS/Fedora-compatible .rpm should cover a good percentage of end users. Building packages isn't too hard, and there are good howtos online.
for the first part of your question regarding Windows: there's no real standard place for libraries/headers on Windows, so the easy solution is: create your own. Simply provide a single lib/ and include/ on your system and have all your projects use it (by setting the path in a cmake file that you include everywhere). Put all third party libs in there, for example:
your projects:
d:/projects/projectA
d:/projects/projectB
third party stuff:
d:/api/lib/lua.lib
d:/api/include/lua/....
(you can even use symlinks aka 'directory junctions' if you have different version)
and the corresponding cmake file:
include_directories( d:/api/include )
link_directories( d:/api/lib )
Okay, so this is one of the basic questions and while I myself might not come across very clear on this, here goes:
While building a project, your compiler will need to find the header files of the libraries. The headers must be in the include path.
after compilation is done, the linker will look for the library binaries (files.so or something like that). These must be in the Library path.
That's the basics.
If you have some specific libaries, you can add them to your own project-specific lib/ and include/ directories and add them to the include path and the library path respectively.
Adding these dirs to these paths can be done in many ways, depending upon how you are building the project. I'm sure there is something called LD_PATH involved in all this... But I don't really know the specifics involved with CMake.
A little googling can help you do the above with CMake.
Hope that helps,
jrh
If you are installing the libraries with a package manager, they will probably all end up in the right place. If not you can get the compiler to search for the by providing the an additional search path using the -L <path> flag. You should be able to pass this extra flag to CMake.
Incidentally the -I <path> can be used to add an extra directory to search for include files.
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