[MacPorts] #37678: MacPorts gcc gives malloc error on correct program using boost, Apple's gcc doesn't

[MacPorts]

#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