I have been trying to find the implementation for the "synchronize" function declared in boost\graph\distributed\mpi_process_group.hpp for serveral hours, but can't find it. Anyone can help?
It's in the library sources, namely here: https://github.com/boostorg/graph_parallel/blob/develop/src/mpi_process_group.cpp#L762
You will usually not have the sources locally if you didn't compile the library yourself (e.g. installing from a package manager).
Related
What's the best way to compile and include a static library (in this case OpenCV) for use in a R package distributed as a binary package. Should I compile it as static outside of R and then put relevant .a files in "inst" or should I include all the source and header files of OpenCV in "inst" and compile from R?
I understand that CRAN will never accept this but it's more for the purpose of making deployment easier for users so they do not need to compile OpenCV or the package from source themselves.
If I get some good pointers on how to proceed or a package that have done something similar I intend to write up a short blog post for other people who want to do the same thing but with other large external libraries (both on Linux, OSX and Windows).
I apologies before hand if I've failed to appreciate that this question has been asked several times before.
I am currently trying to setup a project in C++, b that uses the luabind library. Unfortunately on my distro, namely Arch, this library isn't in the official repos and the one in the AUR is out of date and fails to compile.
Considering that I need the library only for this project I thought that I could make a sandboxed environment similar to python's virtualenv by building the library then installing(copying) the include files and resulting binaries in 2 sub-directories of my project called include and lib, respectively which I'll add to the linking and include paths when building. I understand why distributing the libraries with your project is bad: security and bug fixes in the meantime for example. However distributing DLLs is almost universally done on Windows(which I might do if I cross-compile) and many projects such as games on Linux tend to package their libraries to avoid inconsistencies between disrtos. Moreover if ever need a patched or forked version of a lib I doubt I'll ever find it in any official repo.
So my question is:
Is what I described above a common practice? Should I do it like this?
If not, what is the most commonly-agreed-upon solution to this problem?
NOTE: I use Cmake for build automation, if it matters
EDIT: This question slightly overlaps with mine.
Your approach is interesting, but it is not necessary for you to devise a working system because it has already been done, and luckily, you are only one step away from the solution !
Using CMake, it is easy to automate the building and linking of external source code, using the ExternalProject module.
See http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html for useful information.
This approach has several advantages:
you do not have to include the library's source code in your repository
you can point to the specific version/git tag of the library that you know works with your software OR the latest release if you are certain it will not break compatibility
you do not have to write a complete CMakeLists.txt file to build a possibly complex code base
you can eventually configure the external project to build as a static library so you will not have to distribute shared libraries
you can even completely bypass this if not necessary, by trying to detect a working version of the library on your system with the usual find_package call, and only fall back to building it as an external project if not found
I'm working on a project written in C++ that uses the Boost Regex library to do some parsing. My problem is, I need to run the program on a remote machine that doesn't have the boost library installed. I also don't have admin access to this computer so I can't just install it myself.
Is there any way to separate out just the Boost Regex library so that I can put it in the same directory as my other code? I tried doing this already by downloading the boost library and separating out all of the unneeded headers and such. I managed to get it to a point where it calmost compiled but it failed at the linking stage.
Is there anything I can do to fix this or will I be forced to rewrite the parsing code?
You can use the Boost.BCP tool to extract a subset of Boost.
include the static library libboost_regex-gcc-1_35.a your list of object files to compile.
1_35 is an older version number on my linux box, you may have a newer library
I'm trying to link the thread library of boost 1.50.0 and am having some problems. The problem is that the implementation of the thread cannot be found.
I've checked around here, on random sites and on the official manuals and concluded that there can only be one reason for this (since the actual library I'm linking contains the correct files). There is no auto-linking in MinGW. This means there can be no platform implementation for the threads available (and hence the error).
One of the errors I'm getting is:
undefined reference to `imp__ZN5boost6thread4joinEv'
that comes from myTread.join().
So my questions is, what is the library (or libraries) I need to link in addition to the boost thread library (in this case named libboost_thread-mgw46-mt-1_50.a)?
And furthermore, is there any documentation for all library dependencies in boost?
I could of course be completely wrong, so any help appreciated!
Currenty I'm linking only boosts libraries; threads, chrono and system.
EDIT
To clarify, I'm linking with the following command:
g++ -LPATH_TO_BOOST\lib -o test-boost-thread.exe src\test-boost-thread.o -lboost_thread-mgw46-mt-1_50 -lboost_chrono-mgw46-mt-1_50 -lboost_system-mgw46-mt-1_50
I've tried changing positions of the libraries, but that didn't help.
In your case, given the file name that you posted, the linker line would be -lboost_thread-mgw46-mt-1_50 (remove lib and .a/.so/.lib). There might be (or you might want to create) a symlink that points to it like libboost_thread.a -> libboost_thread-mgw46-mt-1_50.a, in which case you can use the shorter -lboost_thread.
Hmm, seems like I completely forgot about the BOOST_THREAD_USE_LIB flag. Setting this made it work.
Strange error though.
My (C++, cross-platform) app is heavily using Boost libraries (say version 1.x), and I want to also link against a 3rd-party (vendor)'s SDK (no source), itself using Boost (but version 1.y).
So, we both link dynamically against our own version of Boost DLLs, CRT being identical. Consequently, at run-time my app would have to load both DLL of Boost 1.x & 1.y.
What are the potential issues & gotchas associated?
I can't change vendor's SDK, but I can change my app. Maybe I should try to link statically against my Boost 1.x?
PS: Name of Boost's DLL include their version, so no name collision, both are identifiable. Not the usual DLL-hell.
As far as using the DLLs for different versions there should be no problem. At least not on Windows.
This is true if the SDK is using boost internally. If the SDK uses boost constructs in its interface, for example: it has a function that returns a boost::optional, then having multiple versions can cause problems. It could still work fine, dependent on the changes between the versions, but that will definitely be a risk. I don't know of any good solution in that case. This is also true if you include a SDK header file that includes a boost header file.
This is a big problem.
Do a search on DLL hell.
Basically the DLL (or shared libs in Linux) are loaded but not all the names are resolved at load time. What happens is a lazy evaluation, so the names are evaluated on first use. The problem is that if 2 dll have the same name then the location where the name is resolved to depends on the what order the DLL are searched in (which depends on load order).
If you statically link then you will not have problems with method calls as yours will all be resolved at compile time and the third party will be resolved at runtime from the DLL. But what about structures that are created by version-1 boost. If you then pass these to the third party library that then passes it to the version-x boost. Are the structures layed out in the same way?
This is a very tricky area and when problems occur very hard to de-bug.
So try and use the same version.
If you write a function foo, and export it from F.dll, and another function foo exported from G.dll, would you expect problems?
When AF.exe is linked, the linker is told: put some code in there that loads the address of function foo from F.dll. Now BG.dll is linked to retrieve the foo address from G.dll. I still see no problem.
Now replace AF.exe with your app, BG.dll with your vendor's app, F.dll with your boost version, G.dll with the vendor's boost version.
Concluding: I see no problems if the dll names are different.