#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