libgcc 9 dependency cctools requires libunwind-headers with which libgcc9 cannot be built

[vdoublie]

dependencies incompatibility between cctools dependencies and libgcc9 through libunwind-headers

sysadmin@pc61 ~ % sudo /opt/local/bin/port deps cctools
Full Name: cctools @921_3+llvm80
Build Dependencies:   libunwind-headers
Library Dependencies: llvm-8.0

sudo /opt/local/bin/port deps libgcc9
Full Name: libgcc9 @9.2.0_0
Extract Dependencies: xz
Build Dependencies:   cctools, gmp, isl, ld64, libiconv, libmpc, mpfr
Library Dependencies: zlib

this happens trying to build libgcc9 (or gcc9) from source

--->  Configuring libgcc9
Error: libgcc9 cannot be built while libunwind-headers is active.
Error: Please forcibly deactivate libunwind-headers, e.g. by running:
Error: 
Error:     sudo port -f deactivate libunwind-headers
Error: 
Error: Then try again. You can reactivate libunwind-headers again later.
Error: Failed to configure libgcc9: libunwind-headers is active

manually de-activating libunwind-headers solves the pb, however this is a problem.

A quick look in the history of "bugs" this is a recurring issue

[kencu (Ken)]

You've correctly described the problem.

It turns out to be quite difficult to force gcc9 to ignore the libunwind headers during the build if they are already installed. You might think we could find a way to get gcc9 to build correctly against the current libunwind headers, but so far that has eluded us, at least on some systems. Even if we did fix that issue, propagating it back through all the gcc versions we support would be big job.

I think only a few ports need the libunwind headers, and then only to build, but there is no sanctioned way to have a port deactivate a build dependency after it is installed. There is a way to make macports forcibly deactivate a port during a build of another port, the "deactivate hack", but this has been frowned upon (disallowed) for use in this situation in other ports, so I have not bothered to pursue that approach to solving this issue.

The buildbots purge all ports prior to building, and reinstall only the listed build deps for a given port, and so they escape this issue. So most people never see this.

It could be that we would discover this issue only affects certain system versions, and the conflicts-build might not need to apply to every os version; that would lessen the problem a bit, at least.