[MacPorts] #35172: boost @ 1.50 - Error Building boost
MacPorts
noreply at macports.org
Mon Jul 16 17:42:15 PDT 2012
#35172: boost @ 1.50 - Error Building boost
-----------------------------------+----------------------------------------
Reporter: notinmyhead@… | Owner: adfernandes@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.1.1
Keywords: | Port: boost
-----------------------------------+----------------------------------------
Comment(by ecronin@…):
For a number of OS versions we still nominally support (I don't know which
ones gcc 4.7 removes support for) the default gcc the other ports will be
using unless overridden is more than a few years old. I'm also not at all
sure what mixing the gcc and clang/llvm c++ std libraries adds to the
party since I don't think they share any source. Because of how much of
boost is inline code I've never been too sure how much the "if it's
consistent withing the same .so it's safe" advice holds. I'm pretty sure
I ran into issues with boost on RHEL 5.5 when going from the system gcc
(4.1.something) to gcc-devel (4.4.something) for our app but boost still
being gcc 4.1 compiled. I agree that it should be self-contained, just
that because of how tightly boost couples itself to the compiler, in
experience it hasn't been for me...
The idea with the portgroup would be to force the dependent ports to use
configure.compiler=${boost_compiler_version} and anything else that might
be needed. The versioned (by compiler and boost version) boost installs
are nice (but a pain to get bjam to do), but break everything just looking
for include/boost and lib/libboostfoo.dylib. And don't help here when
boost doesn't support the OS' default compiler.
--
Ticket URL: <https://trac.macports.org/ticket/35172#comment:8>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list