bladeRF @20181024_1 fails to build on Mavericks

[tehcog (tehcog)]

Please see attached log file.

Oct 30 16:14:05 xxxXXXxxx --->  Attempting to fetch bladeRF-20181024_1+tecla.darwin_13.x86_64.tbz2 from http://sea.us.packages.macports.org/macports/packages/bladeRF
Oct 30 16:14:06 xxxXXXxxx --->  Verifying checksums for bladeRF
Oct 30 16:14:06 xxxXXXxxx --->  Extracting bladeRF
Oct 30 16:14:06 xxxXXXxxx --->  Applying patches to bladeRF
Oct 30 16:14:06 xxxXXXxxx --->  Configuring bladeRF
Oct 30 16:14:11 xxxXXXxxx --->  Building bladeRF
Oct 30 16:14:12 xxxXXXxxx Error: Failed to build bladeRF: command execution failed
Oct 30 16:14:12 xxxXXXxxx Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_bladeRF/bladeRF/main.log for details.

[tehcog (tehcog)]

log

[jmroot (Joshua Root)]

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_bladeRF/bladeRF/work/bladeRF-9640eec3b97dc0c721018aa02bc47894a300a8ad/host/common/src/osx/clock_gettime.c:32:19: error: unknown type name 'clockid_t'; did you mean 'clock_id_t'?
:info:build int clock_gettime(clockid_t clk_id, struct timespec *tp)int clock_gettime(clockid_t clk_id, struct timespec *tp)
:info:build                   ^~~~~~~~~                  ^~~~~~~~~
:info:build                   clock_id_t                  clock_id_t
:info:build /usr/include/mach/clock_types.h:53:13: note: 'clock_id_t' declared here
:info:build typedef int     clock_id_t;                     /* clock identification type */
:info:build                 ^

[kencu (Ken)]

Hmm. See also where Ryan reported this error in another port <​https://github.com/swoole/swoole-src/issues/1364> and <​https://github.com/swoole/swoole-src/pull/1365/files>

[jmroot (Joshua Root)]

So, clockid_t and clock_id_t are indeed completely different types. The former is (at least on High Sierra) declared in time.h and is specified by posix. The latter is a Mach thing.

[kencu (Ken)]

On that fix of Ryan's report, they seem to just swap them interchangeably:

#ifndef HAVE_CLOCK_GETTIME
 #if defined(__APPLE__) || defined(__MACH__)
     int clock_gettime(clock_id_t which_clock, struct timespec *t);
 #elif defined(__linux__)
     int clock_gettime(clockid_t which_clock, struct timespec *t);
 #endif
#endif
#endif

[cjones051073 (Chris Jones)]

OK, so this is a package that internally has its own clock_gettime workarounds, that appear to be interfering with those added in the legacy-support PortGroup. One quick fix is to turn off this support for all but OSX10.6, which is what it was previous only active for using the old snowleopardfixes port. I'll take a look.

[cjones051073 (Chris Jones)]

Looking at the above, another thing we should probably do is add a definition of HAVE_CLOCK_GETTIME when the legacy fallback is added. This appears to be defined, in newer systems it

 > grep -r HAVE_CLOCK_GETTIME /usr/include
/usr/include/php/main/php_config.h:#define HAVE_CLOCK_GETTIME 1

So I think I will add this as well to the legacy wrapper headers.

[cjones051073 (Chris Jones)]

​https://github.com/macports/macports-ports/commit/095d460dc66bafc5fe0611bbb53ee009a0e05aaf

[michaelld (Michael Dickens)]

Thanks for your work here, Ken & Chris. Sorry for not getting to this ticket; work has been hell with deadlines this past while! It's not normally this intense!

I'll clean up this port & the others that I maintain that use the new legacy PG, since they shouldn't need patching any longer for the "clock_gettime" issue.

Can this ticket be closed? I won't have time to verify that it works for quite some time.