#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 |
---|
comment:2 Changed 5 years ago by raimue (Rainer Müller)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 5 years ago by kencu (Ken)
looks like 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.
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 follow-up: 6 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 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.
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.