[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:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:  2.1.2
Resolution:                   |   Keywords:
      Port:  boost libstdcxx  |
------------------------------+--------------------------------

Comment (by ecronin@…):

 Replying to [comment:13 sean@…]:
 > Replying to [comment:12 ryandesign@…]:
 > > Replying to [comment:7 sean@…]:
 > > > It adds variants to boost to allow selecting +gcc44 all the way to
 +gcc47, also +clang31 all the way to +clang33, and +dragonegg3X as well.
 It uses the full path, so it doesn't need 'port select' at all.
 > >
 > > Adding compiler variants to boost would not be an acceptable solution
 because it would give users the simple ability to break all existing ports
 using boost; I don't want it to be that easy for users to shoot themselves
 in the foot.
 >
 > You actually already have this because of the +openmpi variant. A user
 can just,
 >
 > $ port install openmpi +gcc47
 > $ port install boost +openmpi
 >
 > I think this is, unfortunately, the price to pay for wanting to use
 something that depends on boost :-/ If the whole variant dependence issue
 was solved, that would mitigate some of these issues, but that's a whole
 other issue (get it? issue? hah!).

 boost +openmpi was probably added before +gcc45 was a default variant to
 openmpi, but even back then foot shooting was possible as you noted.
 Today I think it's all but guaranteed since installing boost +openmpi
 without a version of openmpi already installed will default to be broken.
 It should probably at least be using the active_variants group to ensure
 that things are ok at build/activate, but I don't think we can prevent
 issues after the fact from activating a different openmpi (which is why
 non-conflicting subports are better than variants)

-- 
Ticket URL: <https://trac.macports.org/ticket/37678#comment:14>
MacPorts <http://www.macports.org/>
Ports system for Mac OS