Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#60121 closed defect (fixed)

git-lfs @2.10.0 build cannot find <sys/clonefile.h> on macOS 10.11

Reported by: snowflake (Dave Evans) Owned by: raimue (Rainer Müller)
Priority: Normal Milestone:
Component: ports Version: 2.6.99
Keywords: legacy-os Cc:
Port: git-lfs

Description

The build fails within 5 seconds of starting with this error:

GOOS=darwin GOARCH=amd64 go build -ldflags=" -X github.com/git-lfs/git-lfs/config.GitCommit= -s -w " -gcflags="all=-trimpath="$HOME" " -asmflags="all=-trimpath="$HOME"" -trimpath -o ./bin/git-lfs ./git-lfs.go
# github.com/git-lfs/git-lfs/tools
tools/util_darwin.go:21:10: fatal error: 'sys/clonefile.h' file not found
#include <sys/clonefile.h>

According to locate, this file does exist in two places for macOS:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/clonefile.h
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/clonefile.h

but it is not in /usr/include/sys

clonefile is a system call which is implemented in macOS 10.12.x and later.

There may be some logic in trying to include a file which either warns that clonefile is not available or which may not even exists on even older versions of macOS, but it eludes me at the moment.

My system:

"macports_version": "2.6.99",
    "osx_version": "10.11",
    "os_arch": "i386",
    "os_platform": "darwin",
    "build_arch": "x86_64",
    "cxx_stdlib": "libc++",
    "gcc_version": "9.2.0",
    "xcode_version": "8.2.1",
    "clt_version": "8.2.0.0.1.1480973914"

Change History (6)

comment:1 Changed 5 years ago by raimue (Rainer Müller)

Keywords: legacy-os added

Thank you for the report. However, as OS X 10.11 is an old and outdated OS version, I will not look into fixing this myself. If you or anyone else can provide a patch to fix this issue, I will happily apply it.

comment:2 Changed 5 years ago by raimue (Rainer Müller)

Resolution: fixed
Status: assignedclosed

In e10823eb72d83d869daf1853249c182fb3b2acec/macports-ports (master):

git-lfs: Incompatible with macOS <= 10.11

This software needs clonefile(3) which is available as of macOS 10.12.

Closes: #60121

comment:3 Changed 5 years ago by kencu (Ken)

looks ike it is optionally used if available. <https://github.com/git-lfs/git-lfs/pull/3745/files?>.

So the Mac way would be to build it against a newer sdk. Alternatively you could patch it to disable the function if the header doesn't exist.

Adding the function to legacysupport doesn't seem possible as it is an apsf-specific feature, but it's conceivable a non-destructive similar replacement might be found, like using copyfile instead perhaps.

Version 0, edited 5 years ago by kencu (Ken) (next)

comment:4 Changed 5 years ago by snowflake (Dave Evans)

There is an upstream PR at https://github.com/git-lfs/git-lfs/issues/3999

It's about building on 10.11.6

bk2204 commented on Jan 23 2020 and suggested building with CGO_ENABLED=0

I tried make CGO_ENABLED=0 and within 2 seconds there was a 12MB git-lfs executable in the bin directory. I've no idea if it works, but it certainly gave help if invoked.

comment:5 Changed 5 years ago by raimue (Rainer Müller)

With CGO_ENABLED=0, the binary will not link with any C libraries and the downside could be that you will miss features. Often performance could also be affected because an unoptimized Go implementation will be used instead instead of a C library tuned for the target architecture. In this case, it looks like nothing else in git-lfs would need cgo, but I did not check any of the imported modules.

comment:6 in reply to:  5 Changed 5 years ago by snowflake (Dave Evans)

Replying to raimue:

With CGO_ENABLED=0, the binary will not link with any C libraries and the downside could be that you will miss features. Often performance could also be affected because an unoptimized Go implementation will be used instead instead of a C library tuned for the target architecture. In this case, it looks like nothing else in git-lfs would need cgo, but I did not check any of the imported modules.

Agreed. I won't submit any patches but I'll probably keep it as a local ports. For the amount I actually use it (1 repository out of dozens) I can live with the performance hit and loss of features.

Note: See TracTickets for help on using tickets.