c-ares @1.30.0_0: fatal error: 'os/availability.h' file not found

[sambthompson (Sam Thompson)]

c-ares @1.30.0_0 fails to build on OS X El Capitan (and earlier, back to Mountain Lion):

​https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/268051/steps/install-port/logs/stdio

In file included from /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_c-ares/c-ares/work/c-ares-1.30.0/src/lib/ares_sysconfig_mac.c:54:
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_c-ares/c-ares/work/c-ares-1.30.0/src/lib/thirdparty/apple/dnsinfo.h:31:10: fatal error: 'os/availability.h' file not found

Prior version 1.28.1_0 not affected. OS versions prior (Lion/Snow Leopard) buildbot logs show different errors, not investigated.

[sambthompson (Sam Thompson)]

Fix for #64826 may be relevant.

[ryandesign (Ryan Carsten Schmidt)]

The place to report the issue would be ​https://github.com/c-ares/c-ares/issues

[sambthompson (Sam Thompson)]

Replying to ryandesign:

The place to report the issue would be ​https://github.com/c-ares/c-ares/issues

OK, there might be some other weirdness going on here. It appears c-ares (now) has a minimum OS version of 10.12, but the configure test isn't failing as it should (there's a related upstream issue ​https://github.com/c-ares/c-ares/issues/454). That's probably the issue to report upstream, possibly to re-open upstream 454.

However, if MacPorts can't/won't do a work-around like for xar, then I think the port file also needs adjustment to limit El Capitan and earlier to c-ares 1.28.1?

It's a bit odd since upstream also implemented a fix in their issue 672 (​https://github.com/c-ares/c-ares/issues/672) which applies to OS versions < 10.9.

[ryandesign (Ryan Carsten Schmidt)]

The reason c-ares checks for macOS 10.12 or later appears to be because that's when clock_gettime was introduced. It looks like it uses the check to skip some clock_gettime functionality on older systems.

MacPorts has the legacy-support library which includes an implementation of clock_gettime for older systems which could be used if needed. The c-ares port doesn't use this yet.

We can include a workaround like we did for xar, but we do not want to carry patches forever. The correct place to report software bugs is to the software's developers. If the developers fix it, we can backport their fix. If they refuse to fix it, then we can attempt our own patch.

[ryandesign (Ryan Carsten Schmidt)]

Replying to sambthompson:

OS versions prior (Lion/Snow Leopard) buildbot logs show different errors, not investigated.

I filed ​https://github.com/c-ares/c-ares/issues/782 for that.

[sambthompson (Sam Thompson)]

Replying to ryandesign:

The reason c-ares checks for macOS 10.12 or later appears to be because that's when clock_gettime was introduced. It looks like it uses the check to skip some clock_gettime functionality on older systems.

Thanks for looking into this, and reporting the errors for the earlier OS X versions upstream.

The correct place to report software bugs is to the software's developers. If the developers fix it, we can backport their fix. If they refuse to fix it, then we can attempt our own patch.

Not sure if unsupported versions not compiling would be considered a bug, or whether bugs would be accepted for versions considered unsupported. However, I was not able to find any clear declaration from c-ares that Mac OS X < 10.12 is not supported, so have filed ​https://github.com/c-ares/c-ares/issues/783 for this problem. Hopefully they'd be willing to adopt the tweak needed for clock_gettime support if that's the obstacle, so all Mac users of c-ares get the benefit, and not just MacPorts (if they decline and the patch has to be in MacPorts).

[barracuda156]

It is worse that just an incorrect header: #70208

[tobypeterson]

Looks like they added the <fcntl.h> include upstream. For <os/availability.h>, it looks like they simply copied from an Apple open source header. I think you may be able to make progress if you delete that include and the API_AVAILABLE attributes. Looks like you can also delete the _dns_configuration_ack declaration, it isn't used.

[tobypeterson]

Alternatively we'll just have to stick older OS versions on 1.28.1, but that isn't ideal considering that c-ares does have the occasional CVE. (Most recent one was just this February.)

[sambthompson (Sam Thompson)]

Replying to tobypeterson:

that isn't ideal considering that c-ares does have the occasional CVE. (Most recent one was just this February.)

Agreed. Upstream haven't (yet) rejected the report but are engaging with it (and the other issue affecting even earlier OS versions), so would hope to still get a fixed 1.30.1. EDIT: Fixed upstream. Hopefully there's a point release soon.

[barracuda156]

Replying to sambthompson:

Replying to tobypeterson:

that isn't ideal considering that c-ares does have the occasional CVE. (Most recent one was just this February.)

Agreed. Upstream haven't (yet) rejected the report but are engaging with it (and the other issue affecting even earlier OS versions), so would hope to still get a fixed 1.30.1. EDIT: Fixed upstream. Hopefully there's a point release soon.

The build is fixed, but unfortunately it is unusable at the moment, at least with curl.

I will work with upstream to have it fixed.

Could someone try it on an x86 < 10.12 system? For me git fetch fails if curl is built as +ares with c-ares 1.30.0 (and a patch from upstream). Activating 1.28.1 fixes it. curl with no c-ares also works normally.

[sambthompson (Sam Thompson)]

Replying to barracuda156:

The build is fixed, but unfortunately it is unusable at the moment, at least with curl.

I think partially. The further set of issues for earlier OSes, covered in #70208 (c-ares issues 782/784) may be the remainder.

I will work with upstream to have it fixed.

Could someone try it on an x86 < 10.12 system? For me git fetch fails if curl is built as +ares with c-ares 1.30.0 (and a patch from upstream). Activating 1.28.1 fixes it. curl with no c-ares also works normally.

Having rebuilt curl with +ares (after having successfully built c-ares 1.30.0 (with patch for older include file) on 10.11, it seems to work (unless reverting to the even earlier apple header broke it again).

[barracuda156]

In 716024da0953ba766d759383640212bb0fa63665/macports-ports (master):

c-ares: fix for older systems: patch from upstream

Fixes: #70208
Fixes: #70207