Opened 5 months ago

Closed 5 months ago

#70207 closed defect (fixed)

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

Reported by: sambthompson (Sam Thompson) Owned by: tobypeterson
Priority: Normal Milestone:
Component: ports Version: 2.9.3
Keywords: mountainlion mavericks yosemite elcapitan Cc:
Port: c-ares

Description

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.

Change History (13)

comment:1 Changed 5 months ago by sambthompson (Sam Thompson)

Fix for #64826 may be relevant.

comment:2 Changed 5 months ago by ryandesign (Ryan Carsten Schmidt)

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

comment:3 in reply to:  2 Changed 5 months ago by 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.

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

comment:5 in reply to:  description Changed 5 months ago by 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.

comment:6 in reply to:  4 Changed 5 months ago by 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).

comment:7 Changed 5 months ago by barracuda156

It is worse that just an incorrect header: #70208

comment:8 Changed 5 months ago by 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.

comment:9 Changed 5 months ago by 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.)

comment:10 in reply to:  9 ; Changed 5 months ago by 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.

Last edited 5 months ago by sambthompson (Sam Thompson) (previous) (diff)

comment:11 in reply to:  10 ; Changed 5 months ago by 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.

Last edited 5 months ago by barracuda156 (previous) (diff)

comment:12 in reply to:  11 Changed 5 months ago by 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)).

EDIT: There's now a fix for both these issues upstream, and a PR on MacPorts to pick up the fixes until new upstream release. Thanks to all devs and testers on this.

Last edited 5 months ago by sambthompson (Sam Thompson) (previous) (diff)

comment:13 Changed 5 months ago by barracuda156

Resolution: fixed
Status: assignedclosed

In 716024da0953ba766d759383640212bb0fa63665/macports-ports (master):

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

Fixes: #70208
Fixes: #70207

Note: See TracTickets for help on using tickets.