We (Rocket Software) are trying to build git-lfs on z/OS. The build fails with the following errors.

GOOS= GOARCH= go generate github.com/git-lfs/git-lfs/commands
GOOS=zos GOARCH=s390x go build -ldflags=" -X github.com/git-lfs/git-lfs/config.GitCommit=38ae601d -s -w " -gcflags="all=-trimpath="$HOME" " -asmflags="all=-trimpath="$HOME"" -trimpath -o ./bin/git-lfs ./git-lfs.go
# github.com/olekukonko/ts
../go/pkg/mod/github.com/olekukonko/ts@v0.0.0-20171002115256-78ecb04241c0/ts_x.go:19:14: undefined: syscall.Syscall
# github.com/git-lfs/gitobj/v2
../go/pkg/mod/github.com/git-lfs/gitobj/v2@v2.0.1/tree.go:212:20: constant 4278190080 overflows int32
Makefile:246: recipe for target 'bin/git-lfs' failed
make: *** [bin/git-lfs] Error 2

------------------------------
David Crayford
------------------------------

Hello David. Unfortunately not all packages that are available from GitHub and other sources work out-of-the-box on all platforms. Some do, for sure, but often they need to be ported to a given platform, such as z/OS. We have posted some rudimentary porting instructions here: https://www.ibm.com/docs/en/sdk-go-zos/1.16?topic=porting-applications-zos. I took a quick look at git-lfs, and noted the following steps that would need to be taken to get this ported (there may be others, but these are the ones I caught on a first look):
First, the dependency github.com/olekukonko/ts needs to be ported. It uses a raw syscall that isn't supported on z/OS. To port it, I got the code, added a !zos build tag to ts_other.go and ts_x.go, then created a ts_zos.go based on ts_solaris.go (put in a build tag and changed TIOCGWINSZ to syscall.TIOCGWINSZ). I use "go mod edit -replace" on the git-lfs go.mod file to point to the location of my updated packages. Sometimes I have to do "go mod init" on those packages if they don't have a go.mod file. There is another issue --- git-lfs is using int32 for file mode instead of uint32 -- this has to be changed in several places, the reason being that on z/OS it truly is a uint32. I also found that github/mattn/go-isatty had to have it's go.mod file updated to use "latest' for x/sys/unix.  So, as I said, this is what a cursory look told me - there may be other things that need to be done to finish the porting of git-lfs. If you follow through with these steps you can get a working git-lfs on z/OS. I hope that helps. ...Bill

------------------------------
Bill O'Farrell
------------------------------

Hi Bill. Thank you for taking the time to write such a detailed answer. I've passed this information on to our Ported Tools team with a view to adding it to our Git for z/OS product. I'm not a golang guy but it's obvious now that it's more like porting a C/C++ application then the build once run anywhere characteristics of Java or Python.

Thanks again

------------------------------
David Crayford
------------------------------

Original Message:
Sent: Thu July 08, 2021 03:37 PM
From: Bill O'Farrell
Subject: Compile failures build git-lfs

Hello David. Unfortunately not all packages that are available from GitHub and other sources work out-of-the-box on all platforms. Some do, for sure, but often they need to be ported to a given platform, such as z/OS. We have posted some rudimentary porting instructions here: https://www.ibm.com/docs/en/sdk-go-zos/1.16?topic=porting-applications-zos. I took a quick look at git-lfs, and noted the following steps that would need to be taken to get this ported (there may be others, but these are the ones I caught on a first look):
First, the dependency github.com/olekukonko/ts needs to be ported. It uses a raw syscall that isn't supported on z/OS. To port it, I got the code, added a !zos build tag to ts_other.go and ts_x.go, then created a ts_zos.go based on ts_solaris.go (put in a build tag and changed TIOCGWINSZ to syscall.TIOCGWINSZ). I use "go mod edit -replace" on the git-lfs go.mod file to point to the location of my updated packages. Sometimes I have to do "go mod init" on those packages if they don't have a go.mod file. There is another issue --- git-lfs is using int32 for file mode instead of uint32 -- this has to be changed in several places, the reason being that on z/OS it truly is a uint32. I also found that github/mattn/go-isatty had to have it's go.mod file updated to use "latest' for x/sys/unix.  So, as I said, this is what a cursory look told me - there may be other things that need to be done to finish the porting of git-lfs. If you follow through with these steps you can get a working git-lfs on z/OS. I hope that helps. ...Bill

------------------------------
Bill O'Farrell
------------------------------

Glad I could help a little. I'll just add that porting Go applications to z is typically a lot easier than porting C/C++ applications in the case where the application is being ported from a little-endian architecture (ex: x86). Go already has endianness compatibility built-in, where as C/C++ applications tend to have lots of deeply-buried endian-specific code in them. This I know from personal experience :-)

------------------------------
Bill O'Farrell
------------------------------

Original Message:
Sent: Thu July 08, 2021 09:50 PM
From: David Crayford
Subject: Compile failures build git-lfs

Hi Bill. Thank you for taking the time to write such a detailed answer. I've passed this information on to our Ported Tools team with a view to adding it to our Git for z/OS product. I'm not a golang guy but it's obvious now that it's more like porting a C/C++ application then the build once run anywhere characteristics of Java or Python.

Thanks again

------------------------------
David Crayford
------------------------------


Original Message:
Sent: Thu July 08, 2021 03:37 PM
From: Bill O'Farrell
Subject: Compile failures build git-lfs

Hello David. Unfortunately not all packages that are available from GitHub and other sources work out-of-the-box on all platforms. Some do, for sure, but often they need to be ported to a given platform, such as z/OS. We have posted some rudimentary porting instructions here: https://www.ibm.com/docs/en/sdk-go-zos/1.16?topic=porting-applications-zos. I took a quick look at git-lfs, and noted the following steps that would need to be taken to get this ported (there may be others, but these are the ones I caught on a first look):
First, the dependency github.com/olekukonko/ts needs to be ported. It uses a raw syscall that isn't supported on z/OS. To port it, I got the code, added a !zos build tag to ts_other.go and ts_x.go, then created a ts_zos.go based on ts_solaris.go (put in a build tag and changed TIOCGWINSZ to syscall.TIOCGWINSZ). I use "go mod edit -replace" on the git-lfs go.mod file to point to the location of my updated packages. Sometimes I have to do "go mod init" on those packages if they don't have a go.mod file. There is another issue --- git-lfs is using int32 for file mode instead of uint32 -- this has to be changed in several places, the reason being that on z/OS it truly is a uint32. I also found that github/mattn/go-isatty had to have it's go.mod file updated to use "latest' for x/sys/unix.  So, as I said, this is what a cursory look told me - there may be other things that need to be done to finish the porting of git-lfs. If you follow through with these steps you can get a working git-lfs on z/OS. I hope that helps. ...Bill

------------------------------
Bill O'Farrell

Your help is very much appreciated. Do you have a Slack channel for z/OS go where we can collaborate? We participated in the closed beta for Go but it's not until you start to use something in anger that the issues pop up. We very much welcome golang on z/OS as we can now run important software stacks such as Prometheus/Grafana natively. I have a keen interest in the ongoing clang/LLVM open source port in the hope that it's possible to port the Rust language to z/OS.

------------------------------
David Crayford
------------------------------

Original Message:
Sent: Fri July 09, 2021 03:18 PM
From: Bill O'Farrell
Subject: Compile failures build git-lfs

Glad I could help a little. I'll just add that porting Go applications to z is typically a lot easier than porting C/C++ applications in the case where the application is being ported from a little-endian architecture (ex: x86). Go already has endianness compatibility built-in, where as C/C++ applications tend to have lots of deeply-buried endian-specific code in them. This I know from personal experience :-)

------------------------------
Bill O'Farrell
------------------------------


Original Message:
Sent: Thu July 08, 2021 09:50 PM
From: David Crayford
Subject: Compile failures build git-lfs

Hi Bill. Thank you for taking the time to write such a detailed answer. I've passed this information on to our Ported Tools team with a view to adding it to our Git for z/OS product. I'm not a golang guy but it's obvious now that it's more like porting a C/C++ application then the build once run anywhere characteristics of Java or Python.

Thanks again

------------------------------
David Crayford


Original Message:
Sent: Thu July 08, 2021 03:37 PM
From: Bill O'Farrell
Subject: Compile failures build git-lfs

Hello David. Unfortunately not all packages that are available from GitHub and other sources work out-of-the-box on all platforms. Some do, for sure, but often they need to be ported to a given platform, such as z/OS. We have posted some rudimentary porting instructions here: https://www.ibm.com/docs/en/sdk-go-zos/1.16?topic=porting-applications-zos. I took a quick look at git-lfs, and noted the following steps that would need to be taken to get this ported (there may be others, but these are the ones I caught on a first look):
First, the dependency github.com/olekukonko/ts needs to be ported. It uses a raw syscall that isn't supported on z/OS. To port it, I got the code, added a !zos build tag to ts_other.go and ts_x.go, then created a ts_zos.go based on ts_solaris.go (put in a build tag and changed TIOCGWINSZ to syscall.TIOCGWINSZ). I use "go mod edit -replace" on the git-lfs go.mod file to point to the location of my updated packages. Sometimes I have to do "go mod init" on those packages if they don't have a go.mod file. There is another issue --- git-lfs is using int32 for file mode instead of uint32 -- this has to be changed in several places, the reason being that on z/OS it truly is a uint32. I also found that github/mattn/go-isatty had to have it's go.mod file updated to use "latest' for x/sys/unix.  So, as I said, this is what a cursory look told me - there may be other things that need to be done to finish the porting of git-lfs. If you follow through with these steps you can get a working git-lfs on z/OS. I hope that helps. ...Bill

------------------------------
Bill O'Farrell