I recently upgraded my homebrew-installed packages, and after "Trinity-rnaseq" upgraded from 2.4 to 2.5, I received the following warning"
Warning: homebrew/science/trinity dependency boost was built with a different C++ standard library (libc++ from clang). This may cause problems at runtime.
I'm somewhat new to homebrew as a whole, and was wondering what the safest way to fix the boost dependency would be, if it is even necessary.
Thank you!
Rebuild boost and then anything that depends on boost and then your project. And yes, if any of that uses boost as part of a public interface it can easily be a problem.
Related
In windows 'm building a C++ project that I have working in Linux that uses the GMP library. I am using the precompiled static MinGW library and include files from here - http://cs.nyu.edu/~exact/core/gmp/index.html
Everything seems to go well (mpz_init, mpz_mul, etc.) except when I get to mpz_powm_sec().
mpz_powm_sec(m, c, d, n);
That line gives:
error: 'mpz_powm_sec' was not declared in this scope
Yet none of my other references to GMP do. Does anyone know why this is happening and what I can do to make it compile?
The official website for GMP is https://gmplib.org/. The version you downloaded from that third-party website is more than 12 years old, the library has evolved quite a bit since then.
Notwithstanding the official GMP website at https://gmplib.org, the canonical source for precompiled binaries for use with MinGW.org's compiler tool chain is the SourceForge repository at https://sourceforge.net/projects/mingw/files/; the latest MinGW build of GMP is https://sourceforge.net/projects/mingw/files/MinGW/Base/gmp/gmp-5.1.2/, (you will need the "-dev" package, for headers and import libraries, and likely the "-dll" for runtime bindings).
If you use binaries which have been prepared by the MinGW developers themselves, they will have been tested in conjunction with MinGW; if you grab third party builds, they may well be out of date, may not work, and you're pretty much on your own.
I'm getting the error Parse error at "BOOST_JOIN" while trying to compile a code with Qt4 and CGAL. I'm not using Boost directly and I've already searched and tried a bunch of options like -DBOOST_TT_HAS_OPERATOR_HPP_INCLUDEDand -DBOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION. The versions I'm working with are CGAL 4.1.0, Qt 4.8.4_6 and Boost 1.53.0_1, and using CMake to generate the Makefile, in a machine Mac OS 10.8.2. Any ideas of what could be causing that error?
This problem happens in Boost 1.56.0 with QT 4.7.4 (which is quite old now),
Regardless, another quick workaround is to edit the problematic boost header files,
and
add to the top:
#ifndef Q_MOC_RUN
add to the bottom:
#endif
This will at least let MOC run without dying.
When you compile a piece of code that defines Qt objects, the build system needs to call the Qt Meta Object Compiler, aka "moc". In Qt versions before 5.0, the "moc" compiler (actually a precompiler) does not parse correctly all C++ code. In particular, it does not fully expand preprocessor macros. In recent Boost versions, some macros (like that BOOST_JOIN) are sometimes used to define a namespace name. For example:
namespace BOOST_JOIN(BOOST_TT_TRAIT_NAME,_impl) {
in boost/type_traits/detail/has_binary_operator.hpp of Boost version 1.53.
A Qt bug has being filled at Qt-Project.org and is said to be fixed in Qt-5.0.
In CGAL-4.2, I have tried to suppress those build errors by separating more the use of Qt and Boost in different compilation units. You should retry with a recent version of Boost, and CGAL-4.2-beta1 (or later versions if they are released when you read that answer). Let me know if you encounter similar problems with CGAL-4.2-beta1 or later.
As for Qt-5.0, I hope CGAL-4.3 will support it. We will have to work on the CMake scripts to support it. It will be added to the planning of the next CGAL developers meeting.
I downgraded to Boost 1.52, and now it's compiling.
I want to move my current project to C++11. The code all compiles using clang++ -std=c++0x. That is the easy part :-) . The difficult part is dealing with external libraries. One cannot rely on linking one's C++11 objects with external libraries that were not compiled with c++11 (see http://gcc.gnu.org/wiki/Cxx11AbiCompatibility). Boost, for example, certainly needs re-building (Why can't clang with libc++ in c++0x mode link this boost::program_options example?). I have source for all of the external libraries I use, so I can (with some pain) theoretically re-build these libs with C++11. However, that still leaves me with some problems:
Developing in a mixed C++03/C++11 environment: I have some old projects using C++03 that require occasional maintenance. Of course, I'll want to link these with existing versions of external libraries. But for my current (and new) projects, I want to link with my re-built C++11 versions of the libraries. How do I organise my development environments (currently Ubuntu 12.04 and Mac OS X 10.7) to cope with this?
I'm assuming that this problem will be faced by many developers. It's not going to go away, but I haven't found a recommended and generally approved solution.
Deployment: Currently, I deploy to Ubuntu 12.04 LTS servers in the cloud. Experience leads one to depend (where possible) on the standard packages (e.g. libboost) available with the linux distribution. If I move my current project to c++11, my understanding is that I will have to build my own versions of the external libraries I use. My guess is that at some point this will change, and their will be 'standard' versions of library packages with C++11 compatibility. Does anyone have any idea when one might expect that to happen? And presumably this will also require a standard solution to the problem mentioned above - concurrent existence of C++03 libs and C++11 libs on the same platform.
I am hoping that I've missed something basic so that these perceived problems disappear in a puff of appropriate information! Am I trying to move to C++11 too soon?
Update(2013-09-11): Related discussion for macports: https://lists.macosforge.org/pipermail/macports-users/2013-September/033383.html
You should use your configure toolchain (e.g. autotools) to "properly" configure your build for your target deployment. Your configuration tests should check for ABI compatible C++11 binaries and instruct the linker to use them first if detected. If not, optionally fail or fallback to a C++03 build.
As for C++11 3rd part libraries installed in a separate parallel directory tree, this isn't strictly necessary. Library versioning has been around for a long time and allows you to place different versions side by side on the system or wherever you'd like, again based on configure.
This might seem messy, but configure toolchains were designed to handle these messes.
I just had a quick look at the documentation and the C++ source of the protocol buffers and I could not find any library requirements to build the protobuf runtime - either as shared library or static library.
Does anyone know what the requirements are?
(I am suspecting that it only relies on C++ and the STL)
(I am suspecting that it only relies on C++ and the STL)
AFAIK you're suspecting right, there aren't any further dependencies.
UPDATE:
I have checked the docs again and couldn't find any mention for the need of other libraries to link the code generated by the protoc compiler (and I'm pretty sure they would have mentioned this).
We're using protobuf on embedded systems that run non standard OS (FreeRTOS actually), and I can't remember any difficulties with missing extra stuff necessary to integrate it. GCC 4.6 (arm-none-eabi) is used as cross toolchain.
Does anyone have any experience with running C++ applications that use the boost libraries on uclibc-based systems? Is it even possible? Which C++ standard library would you use? Is uclibc++ usable with boost?
We use Boost together with GCC 2.95.3, libstdc++ and STLport on an ARMv4 platform running uClinux. Some parts of Boost are not compatible with GCC 2.x but the ones that are works well in our particular case. The libraries that we use the most are date_time, bind, function, tuple and thread.
Some of the libraries we had issues with were lambda, shared_pointer and format. These issues were most likely caused by our version of GCC since it has problems when you have too many includes or deep levels of template structures.
If possible I would recommend you to run the boost test suite with your particular toolchain to ensure compatibility. At the very least you could compile a native toolchain in order to ensure that your library versions are compatible.
We have not used uClibc++ because that is not what our toolchain provider recommends so I cannot comment on that particular combination.
We are using many of the Boost libraries (thread, filesystem, signals, function, bind, any, asio, smart_ptr, tuple) on an Arcom Vulcan which is admittedly pretty powerful for an embedded device (64M RAM, 533MHz XScale). Everything works beautifully.
GCC 3.4 but we're not using uclib++ (Arcom provides a toolchain which includes libstd++).
Many embedded devices will happily run many of the Boost libraries, assuming decent compiler support. Just take care with usage. The Boost libraries raise the level of abstraction and it can be easy to use more resources than you think.
I googled "uclibc stlport". It seems there are at least a few versions of uclibc for which stlport can be compiled (see this).
Given that, i'd say Boost is just a few compilation steps away. I have read a message by David Abrahams (who is an active member of the boost community) that says that Boost does not depend directly on the used libc. But some libraries may still cause problems, Boost.Python for instance, since it depends on something else (Python in my example) that might be difficult to compile with uclibc.
Hope this helps
I have not tried but I don't know anything about uclibc that would prevent Boost from working.
Try it and see what happens, I would say.
Yes you can use boost with uclibc.
I tried this with boost 1.45 & uclibc on ARM9260
Use fresh OpenEmbedded
Configure it to use Angstrom
Configure Angstrom to use uclibc
make boost - bitbake boost