#37678: MacPorts gcc gives malloc error on correct program using boost, Apple's gcc doesn't ------------------------------+-------------------------------- Reporter: yusuhail@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: worksforme | Keywords: Port: boost libstdcxx | ------------------------------+-------------------------------- Changes (by adfernandes@…): * status: new => closed * resolution: => worksforme Comment: Replying to [comment:11 ecronin@…]:
I don't believe boost is sadistic enough yet to have bjam process the headers installed, so multiple compilers could share the same $prefix/include/boost. Boost also supports versioned library names which allow you to install boost for multiple compilers into the standard location at the cost of needing -lboost_system-gcc47-mt instead of just -lboost_system.
This is correct. The major problem with boost is that it has one-header- for-all that changes all sorts of interface assumptions about how the libraries were built, and it's terrible with encapsulation. Basically, this means that the compiler that processes the boost headers needs to be the same compiler that built the libraries. That's why they added the brain-dead `-lboost_system-gcc47-mt` stuff. MPI is a different issue. The openmpi headers encapsulate the interfaces quite well, so you '''can''' do things like mix dylibs compiled with different compilers. As long as the headers correctly specify the (constant) interfaces to the dylibs, it doesn't matter what compiler creates the dylibs. (There are side-issues with this, such as people using different c++ std libraries by accident, but those are side issues.) Basically, my experiences with boost are that it really his horrible to use as a system library if you have multiple compilers. It was designed and tested in '''one''' configuration - the one that uses the system compiler. The "one system compiler to rule them all" is kind-of an old- time concept... but that's what they do. Any variants of boost that specify the compiler would just introduce a reverse-bug; all projects using the boost libraries would then need to use the same compiler... :-) By the way - I just ran the code sample in the report using system gcc-4.2.1, system clang and gcc47 from macports, and all three compiled and ran without problems, so marking as `worksforme` (OS 10.8.2, latest Xcode tools, etc.) -- Ticket URL: <https://trac.macports.org/ticket/37678#comment:16> MacPorts <http://www.macports.org/> Ports system for Mac OS