[MacPorts] #44918: defect: boost @1.56.0_1+no_single+no_static+python27+gcc48 won't build on PPC Tiger (Mac OS X 10.4.11)

[MacPorts]

#44918: defect: boost @1.56.0_1+no_single+no_static+python27+gcc48 won't build on
PPC Tiger (Mac OS X 10.4.11)
------------------------------+--------------------------------
  Reporter:  Peter_Dyballa@…  |      Owner:  macports-tickets@…
      Type:  defect           |     Status:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:  2.3.1
Resolution:                   |   Keywords:
      Port:  boost            |
------------------------------+--------------------------------

Comment (by sean@…):

 Replying to [comment:9 cal@…]:
 > Replying to [comment:8 ryandesign@…]:
 > > > The debug output shows that the gcc48 variant did run, and it also
 shows that MacPorts chose the clang-3.3 compiler for boost. Installing
 llvm-3.3 is the obvious consequence, trying to install a different llvm
 won't help here – the problem is the compiler choice of the boost port.
 You were right in assuming the boost Portfile is to blame.
 > >
 > > Right, I just realized that as well. And llvm-3.3 doesn't build on
 PowerPC; I found the ticket: #39849. It was closed as not to be fixed. So
 it seems there is no compiler in existence that can build the current
 version of boost on a PowerPC Mac.
 >
 > I think GCC would work just fine. The problem is that the
 `compilers-1.0` PortGroup which provides the GCC variants doesn't set
 `configure.compiler`, but it should. If MacPorts would not default to
 selecting a suitable compiler automatically, the build would work, because
 `configure.cc`, `configure.cxx`, etc. are properly set. The problem is
 that `configure.compiler` is being left at its default value, triggering
 auto-selection of compilers.

 Yes, you are correct about how the compilers portgroup behaves currently.
 I pretty much neglect configure.compiler since the compilers portgroup is
 trying to achieve a similar effect via a different way. I'm open to
 suggestions about changing the behavior, though. Thoughts?

-- 
Ticket URL: <https://trac.macports.org/ticket/44918#comment:12>
MacPorts <http://www.macports.org/>
Ports system for OS X