[MacPorts] #59453: R @3.5.1: Fails to compile on Mojave (10.14.6) with XCode 11 (11.1 11A1027)

[MacPorts]

#59453: R @3.5.1: Fails to compile on Mojave (10.14.6) with XCode 11 (11.1 11A1027)
--------------------------+--------------------
 Reporter:  vjorlikowski  |      Owner:  (none)
     Type:  defect        |     Status:  new
 Priority:  Normal        |  Milestone:
Component:  ports         |    Version:  2.6.2
 Keywords:                |       Port:  R
--------------------------+--------------------
 R @3.5.1 is failing to compile on a Mojave (10.14.6) system that has XCode
 11 (11.1 11A1027) installed.

 The build fails with:

 {{{
 :info:build make[4]: Entering directory
 `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_R/R/work/R-3.5.1/src/library/tools'
 :info:build installing 'sysdata.rda'
 :info:build dyld: lazy symbol binding failed: Symbol not found:
 _timespec_get
 :info:build   Referenced from:
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_R/R/work/R-3.5.1/lib/libR.dylib
 :info:build   Expected in: /usr/lib/libSystem.B.dylib
 :info:build dyld: Symbol not found: _timespec_get
 :info:build   Referenced from:
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_R/R/work/R-3.5.1/lib/libR.dylib
 :info:build   Expected in: /usr/lib/libSystem.B.dylib
 :info:build /bin/sh: line 1: 31018 Done                    echo
 "tools:::sysdata2LazyLoadDB(\"./R/sysdata.rda\",\"../../../library/tools/R\")"
 :info:build      31019 Abort trap: 6           | R_DEFAULT_PACKAGES=NULL
 LC_ALL=C R_ENABLE_JIT=0 TZ=UTC ../../../bin/R --vanilla --slave
 :info:build make[4]: *** [sysdata] Error 134
 }}}

 And, when one looks at the config.log output, one finds:

 {{{
 configure:33502: checking whether timespec_get exists and is declared
 configure:33530: /usr/bin/clang -o conftest -pipe -Os
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch
 x86_64 -fPIC  -I/opt/local/include
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
 -L/opt/local/lib -Wl,-headerpad_max_install_names
 -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
 -arch x86_64 conftest.c -lm  >&5
 conftest.c:180:22: warning: 'timespec_get' is only available on macOS
 10.15 or newer [-Wunguarded-availability-new]
   char *p = (char *) timespec_get;
                      ^~~~~~~~~~~~
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/time.h:199:5:
 note: 'timespec_get' has been marked as being introduced in macOS 10.15
 here, but the deployment target is macOS 10.14.0
 int timespec_get(struct timespec *ts, int base);
     ^
 conftest.c:180:22: note: enclose 'timespec_get' in a __builtin_available
 check to silence this warning
   char *p = (char *) timespec_get;
                      ^~~~~~~~~~~~
 1 warning generated.
 configure:33530: $? = 0
 configure:33539: result: yes
 }}}

 It appears that, with XCode 11, timespec_get() has been included in the
 system headers, causing the compiler to kvetch - but still exit
 successfully. As a result, the configure script is given erroneous
 information about timespec_get() support.

 This causes a failure at link time, because timespec_get() is included in
 Catalina (10.15) - but not Mojave (10.14). The "strategy" for working
 around this *appears to be* to wrap things you're not sure will be
 available in builtin_available macros - which doesn't work so well for
 auto-generated test programs in configure.

 I have to wonder how many other such library calls rely on the
 builtin_available check, for supporting Mojave and Catalina at the same
 time...

-- 
Ticket URL: <https://trac.macports.org/ticket/59453>
MacPorts <https://www.macports.org/>
Ports system for macOS