[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 sean@…):

 Replying to [comment:14 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)

 The problems the active_variants approach (especially with compiler
 wrappers) is which variant to use? +gcc44, 45, 46, 47? +clang31, 32, 33?
 etc. Subports would iron out this dependency issue but introduce a drastic
 change in core (i.e. need a way to get a subport's libs / headers).

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