libunwind-headers @3.9.1 installs headers that cause other ports to fail to build

[ryandesign (Ryan Carsten Schmidt)]

boost @1.65.1 failed to build on a Leopard system that had libunwind-headers @3.9.1 installed because:

/opt/local/include/unwind.h:38: error: comma at end of enumerator list

Uninstalling libunwind-headers allowed boost to be compiled.

The port's description says:

This version installs headers outside of the normal filesystem hierarchy in order to not accidentally conflict with the host implementation that other ports may expect.

yet it installs /opt/local/include/unwind.h which is clearly not outside of the normal hierarchy. I guess it doesn't matter if the file can be fixed to not have a comma at the end of the enumerator list.

See also #35667.

[jeremyhu (Jeremy Huddleston Sequoia)]

In 1d446bbc944ab788cea901fda2ea0ace21d9de22/macports-ports:

libunwind: Remove incorrect comment about being installed into a nonstandard path

Fixes: #55430

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@…>

[ryandesign (Ryan Carsten Schmidt)]

Well I was hoping that beyond just changing the description, you would fix the header so that it does not cause the comma at end of enumerator list error. For example, would the attached patch be acceptable?

[jeremyhu (Jeremy Huddleston Sequoia)]

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.

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.

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.

[jeremyhu (Jeremy Huddleston Sequoia)]

That being said, I'm not agains this change to make the header conform with pedantic C89, so feel free to push it in.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #55535.

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

Replying to jeremyhu:

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?

The problem is more boost-specific than I thought: the boost source code itself is doing a #include <unwind.h>, so we can't blame the old compiler for that.

[ryandesign (Ryan Carsten Schmidt)]

In 2c4fbaf661ad58a7ed5ecef17007580c9dbd8601/macports-ports:

libunwind-headers: Make unwind.h c89 compatible

This allows boost to compile on older systems with older compilers that
default to c89 mode (Snow Leopard and earlier with Apple gcc 4.2.1)
when the libunwind-headers port happens to be installed.

Closes: #55430