[MacPorts] #55430: libunwind-headers @3.9.1 installs headers that cause other ports to fail to build

[MacPorts]

#55430: libunwind-headers @3.9.1 installs headers that cause other ports to fail to
build
--------------------------------+----------------------
  Reporter:  ryandesign         |      Owner:  jeremyhu
      Type:  defect             |     Status:  reopened
  Priority:  Normal             |  Milestone:
 Component:  ports              |    Version:
Resolution:                     |   Keywords:
      Port:  libunwind-headers  |
--------------------------------+----------------------

Comment (by ryandesign):

 Replying to [comment:3 jeremyhu]:
 > Having a comma at the end of an enumerator list is not a language
 violation.  It's only an error in cases where you're building -ansi (or
 -std=c89) -pedantic -Werror.  Anything requesting pedantic errors for a
 nearly 3 decade old version of the language is asking for trouble.

 `-std=c89` is how GCC 4.2.1 and earlier (default compiler on Snow Leopard
 and earlier) work by default. It's true that boost seems to be compiling
 with the `-pedantic` flag. Maybe it shouldn't be doing that? What do you
 suggest? Should we prohibit all ports in MacPorts from ever using
 `-pedantic`? Or are you proposing we add conditional code to each port
 that uses `-pedantic` to disable it on old compilers? I'm envisioning that
 being a lot of ongoing effort to discover which ports are doing that. In
 any case, boost has a unique build system that I don't understand, so I
 don't know how to make it not use `-pedantic`. Wouldn't it be easier to
 just commit the previously-attached patch so that this one header is
 pedantic-compliant?

 > Furthermore, while removing the comma to better conform with C89 does
 workaround the warning, it doesn't change the root of the problem and will
 just mask it.

 I guess I'm not sure what root problem you're referring to.

 > My understanding is that gcc uses its own unwinder and NOT the one
 provided by the system.  Thus, it really does need to fix its header
 search paths to locate its own libunwind before looking in the system
 search paths.

 We're talking about the GCC that was included in Xcode on Snow Leopard and
 earlier. Doesn't it use the unwinder provided by the system?

 I'm going to commit the previously-attached patch and revbump libunwind-
 headers to at least get past this error.

--
Ticket URL: <https://trac.macports.org/ticket/55430#comment:6>
MacPorts <https://www.macports.org/>
Ports system for macOS