Opened 7 years ago

Closed 7 years ago

#55430 closed defect (fixed)

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: mrkapqa, michaelld (Michael Dickens)
Port: libunwind-headers

Description

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.

Attachments (1)

unwind.h.diff (393 bytes) - added by ryandesign (Ryan Carsten Schmidt) 7 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: newclosed

In 1d446bbc944ab788cea901fda2ea0ace21d9de22/macports-ports:

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

Fixes: #55430

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

comment:2 Changed 7 years ago by 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?

Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: unwind.h.diff added

comment:3 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by 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.

comment:5 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: mrkapqa added
Resolution: fixed
Status: closedreopened

Has duplicate #55535.

comment:6 in reply to:  3 ; Changed 7 years ago by 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.

comment:7 in reply to:  6 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by michaelld (Michael Dickens)

Cc: michaelld added

comment:9 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.