I'm not sure if technically possible and worth the trouble, but perhaps there's a way to link those functions "by hand" in code? That should already take care of the problem but it seems to me that if go tries to dyld those missing functions anyway it defeats the purpose of checking, which is sad because it means no single binary to support old and new systems even though git-lfs itself apparently could. I'm also puzzled by the checkCloneFileSupported() ("return iff Mac OS version is greater or equal to 10.12.x Sierra"). I'm a bit confused as to why it works though, as the reverted files refer to cgo. V2.13.3, again with #4387 reverted and CGO_ENABLED=0, also compiles and runs, reporting itself as git-lfs/2.13.3 (GitHub darwin amd64 go 1.15.2 git a5e6585). Thank you with #4387 reverted and your hint now compiles and runs, reporting itself as git-lfs/2.13.0 (GitHub darwin amd64 go 1.15.2 git 373de0c). Tools/util_darwin.go:21:10: fatal error: 'sys/clonefile.h' file not found GOOS= GOARCH= go build -ldflags=" -X /git-lfs/git-lfs/config.GitCommit=fc66469 -s -w " -gcflags="all=-trimpath="$HOME" " -asmflags="all=-trimpath="$HOME"" -trimpath -o. Git-lfs: skipping fmt, no goimports found at `goimports`. If you want to create a new branch to retain commits you create, you mayÄo so (now or later) by using -b with the checkout command again. State without impacting any branches by performing another checkout. You can look around, make experimentalĬhanges and commit them, and you can discard any commits you make in this I wonder if that's due to #4387? If you're able, could you try reverting that change from your main branch and see if it helps? It builds, but then misses _clonefileat when run. Tried building current main branch with go version go1.15.2 darwin/amd64. Since you already have a prior version of Git LFS installed, those hooks should be in place already, so you should probably only need to replace the binary.) (Running git lfs install requires that the git-lfs binary already be installed because git lfs install is a command executed by that binary to do some additional setup, such as installing the Git hooks needed to use Git LFS. install.sh from the binary release package, because that will install the git-lfs binary and then also run git lfs install. Should I only run install.sh or do git lfs install -skip-repo like GitHub Desktop does? OK, that checks out with #4437 being the likely cause. If you are able to build Git LFS locally, it should work with Go 1.14 or earlier (as far back as 1.11), which all should in turn support macOS 10.11, I believe. And since this is an open-source project with a limited number of people providing support, I don't think we would want to introduce that kind of discrepancy into our support matrix. but as I say, that would definitely introduce complexity into our support, since we'd then have one flavour of macOS using a different version of Go than all other clients. I suppose we might be able to build for Darwin AMD with an older Go, and for Darwin ARM with Go 1.16, at least for a while. So we would have to find a way to support both newer Apple hardware (which requires newer Go releases) and older hardware - and maybe this would even require a separate build and signed release, just for older Apple hardware, which in turn complicates packaging. And Go 1.15 now requires macOS 10.12 or later. That said, we may not find a simple workaround, as the call to the _clock_gettime() function is not in the Git LFS code directly rather, it's just pulled in via basic Go dependencies, specifically from the x/sys package. Would you be able to install Git LFS directly (not as part of GitHub Desktop) and help us determine the last working Git LFS release on your hardware? I assume this is due to #4437 which switched the release builds to use Go 1.16, but perhaps stems from an earlier change.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |