Bug 13044 - On macOS 10.12.6 with the new Xcode 9, `make check` is full of failures
On macOS 10.12.6 with the new Xcode 9, `make check` is full of failures
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
3.1.2
x86 Mac OS X
: P5 regression
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-09-20 14:07 UTC by chdiza
Modified: 2017-09-20 19:20 UTC (History)
0 users

See Also:


Attachments
Log for `make check` (85.08 KB, text/plain)
2017-09-20 14:07 UTC, chdiza
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description chdiza 2017-09-20 14:07:50 UTC
Created attachment 13614 [details]
Log for `make check`

macOS 10.12.6, `make check` is full of failures using Xcode 9, but all those same tests pass when using Xcode 8.3.3.  I'm attaching a log, but here's an example:

created directory /Users/chdiza/.tmp/tmpdir/rsync-20170920-66113-1rmtqxr/rsync-3.1.2/testtmp/exclude/chk
./
.filt
dyld: lazy symbol binding failed: Symbol not found: _utimensat
  Referenced from: /Users/chdiza/.tmp/tmpdir/rsync-20170920-66113-1rmtqxr/rsync-3.1.2/rsync
  Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _utimensat
  Referenced from: /Users/chdiza/.tmp/tmpdir/rsync-20170920-66113-1rmtqxr/rsync-3.1.2/rsync
  Expected in: /usr/lib/libSystem.B.dylib

rsync: connection unexpectedly closed (132 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.2]
----- exclude log ends
Comment 1 chdiza 2017-09-20 14:36:12 UTC
Hmmm, I can only reproduce this when using Homebrew.  I've reported this to them, so we'll see whether it's their "fault" or whether rsync needs to adjust for Xcode 9.
Comment 2 Andrey Gursky 2017-09-20 15:05:34 UTC
utimensat() specified in POSIX.1-2008 (about 9! years ago) has been (at last!) added in macOS 10.13. So if you've compiled binary using latest Xcode i.e. for macOS 10.13, then it depends on the existence of utimensat() in the libc, which is missing on pre-10.13.
Comment 3 Ben RUBSON 2017-09-20 15:11:47 UTC
Nearly off topic, but what is the embedded rsync version in Mac OS 10.13 ?
10.11 still uses 2.6.9 :| ...
Thx !
Comment 4 chdiza 2017-09-20 18:36:23 UTC
Communicating with Homebrew today, it's still not clear whether this because of anything they're doing, or whether rsync will have to do something to accommodate the combination of Xcode 9 (which only comes with a 10.13 SDK) with macOS 10.12.
Comment 5 Andrey Gursky 2017-09-20 19:12:44 UTC
> Xcode 9 (which only comes with a 10.13 SDK)

I guess you obviously will not be able to compile programs for other macOS versions with such Xcode 9. Unless you install the appropriate SDK manually and point Xcode to use it (if this is possible). From what I know: homebrew has 3 different builds for every package. It is because Apple supports, sure, the very last release, the release many people still have installed and the previous "LTS" release. I suppose each build is made with a suitable SDK, otherwise why to have 3 different builds?
Comment 6 chdiza 2017-09-20 19:20:31 UTC
Homebrew's builds for different macOS versions will use as few versions of Xcode as possible.  Sometimes one version of Xcode is used on two different macOS VMs with differing macOS versions.  Anyway, those are for Homebrew's pre-compiled binaries (and in the case of rsync, they don't run `make check` when building said binaries).  I want to build rsync from source.

I've found that if one manually runs `xcode-select` to point to the folder where the Command Line Tools live (as opposed to pointing at the tools included in Xcode.app), there is no problem with rsync and its tests.

As far as I can see now, this is a bug in Xcode 9.0.

Apple is known to be stubborn about this sort of thing though, so it might require rsync to do some workarounds.