I need to build a Go (1.13+ due to Modules) binary with Travis. The trick is, that I need to use CGO.
Thus, I have a language: cpp and Focal config. The default packaged version with Travis is Go 1.11, though.
So I tried installing Go 1.13:
using apt:
Setting up golang (2:1.13~1ubuntu2) ...
using gimme:
unset GOOS;
unset GOARCH;
export GOROOT='/home/travis/.gimme/versions/go1.13.1.linux.amd64';
export PATH="/home/travis/.gimme/versions/go1.13.1.linux.amd64/bin:${PATH}";
go version >&2;
export GIMME_ENV="/home/travis/.gimme/envs/go1.13.1.env"
When I try to call these specific versions I get errors:
compile: version "go1.11.1" does not match go tool version "go1.13.1"
This is probably due to PATH and other customizations in Travis-Go since:
$ which go
/home/travis/.gimme/versions/go1.11.1.linux.amd64/bin/go
It even fails when with the same error when trying to fix PATH via:
- export PATH="/home/travis/.gimme/versions/go1.13.1.linux.amd64/bin:${PATH}"
- go build
Does anyone know how to override the default Travis Go version or at least reverse Travis Go-changes so that apt Go could be used?
EDIT:
Added some more example output of the Travis instance.
It of course was a very obvious workaround.
Had to also e.g. set:
env:
global:
- GOROOT='/home/travis/.gimme/versions/go1.13.1.linux.amd64'
Still would appreciate any solution that makes this less hacky.
Related
I'm trying to write some unit tests for a poc I'm doing in Golang / Kafka on a new M1 Mac. I'm using the official Golang Kafka libs from confluent:
"github.com/confluentinc/confluent-kafka-go/kafka"
Apparently, this package has a dependency on a librdkafka which is not built for M1 (yet?). For the build, there is a work around here, which goes something like this:
% brew install librdkafka openssl zstd
% PKG_CONFIG_PATH="/opt/homebrew/opt/openssl#3/lib/pkgconfig"
% go build -tags dynamic *yadda yadda yadda*
This is fine for build/run. Unfortunately, it doesn't seem to work for tests. In the link describing the workaround, using go test -tags dynamic ./... seems to work, but in my case the test run doesn't seem to read the exported PKG_CONFIG_PATH:
% go test -tags dynamic ./... -v
# pkg-config --cflags -- rdkafka
Package libcrypto was not found in the pkg-config search path.
Perhaps you should add the directory containing `libcrypto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libcrypto', required by 'rdkafka', not found
pkg-config: exit status 1
FAIL smartAC/shared [build failed]
Even though that env var is set, at least in my shell:
% echo $PKG_CONFIG_PATH
/opt/homebrew/opt/openssl#3/lib/pkgconfig
Is there some trick to get go test tool to see the env var?
Ok, never mind. I sorted this... in my ~/.zshrc I wasn't exporting the PKG_CONFIG_PATH, so I changed this:
PKG_CONFIG_PATH="/opt/homebrew/opt/openssl#3/lib/pkgconfig"
to this:
export PKG_CONFIG_PATH="/opt/homebrew/opt/openssl#3/lib/pkgconfig"
Which seems to work. Leaving the question up, just in case it might help some other noob like me :-).
i'm trying to install a library inside a package. However I don't understand where it compiles to.
Structure is like so:
package/cmd/library
I can install other executable targets fine with go install. My paths are set correctly. However now I want to build my shared library target and deploy it somewhere (this deployment step can be done manually). I'm running into two different issues.
Issue one, I can't seem to install it at all:
go install -buildmode=c-shared bpackage/cmd/library#latest
Returns with:
go install: no install location for directory /home/tpm/go/pkg/mod/package/cmd/library outside GOPATH
For more details see: 'go help gopath'
which tells me that it installs somewhere other than in my gopath, I'm just not sure where that might be.
Issue 2, using the -o flag doesn't work with go install, so I can't seem to alter the output location to place it inside the GOPATH (i did try setting the GOBIN to within my gopath, but since other commands work fine I don't think this should be causing any issue)
Quoting Ian from https://github.com/golang/go/issues/24253
Note that it doesn't make a great deal of sense to use go install -buildmode=c-shared. The expectation is that people will use go build -buildmode=c-shared -o foo.so. The only point of using -buildmode=c-shared is to use the shared library somewhere, and using go install without -o will put the shared library in a relatively unpredictable place.
I'm playing with GraphQL in Go and I was trying to get gqlgen tool using the familiar go run command.
I was expecting it to retrieve the latest available tag, instead I"m somehow getting a tag which does not seem to exist in the repo at all:
$ go run github.com/99designs/gqlgen version
v0.9.1-dev
I would expect the above to return per the latest tag
v0.13.0
Go version installed on my workstation:
$ go version
go version go1.15.5 darwin/amd64
Anyone has any ideas what's going on?
UPDATE: disabling GOPROXY does not help
UPDATE2: it turns out the version is hardcoded into version.go as you can see here, but even if go run gets the master instead of the latest tag, you'd still expect the output to be 0.13.0-dev as per the master branch Instead I suspect there is some string ordering of versions of tags which orders 0.9.* above 0.1*.*
go run does not currently support running a specific version of a binary, but note that there is an accepted Go proposal to add that functionality in a future release of the go command.
As of Go 1.16, you can instead go install the binary at a specific version, and then run that binary from its install location (either $(go env GOBIN) or $(go env GOPATH)/bin).
$ GOBIN=~/bin go install github.com/99designs/gqlgen#latest
$ ~/bin/gqlgen ...
I think the version command was misconfigured on build, and that v0.9.1-dev was not the tag at build time.
I'm trying to create a docker image for use in a build pipeline that has various tools pre-installed for building and testing go projects. One tool we need is golint but I'm struggling to see how to install a specific version of it. The reason I want to lock down the version is to avoid accidental / unwanted / unintended breakages at a later date.
For a start, looking here the versions are not exactly in an easy-to-type format.
Also when I try to use the following command
go get -u golang.org/x/lint/golint#v0.0.0-20181217174547-8f45f776aaf1
I get an error
go: cannot use path#version syntax in GOPATH mode
Googling has so far yielded very few relevant results...
Is what I'm trying to do possible? Many thanks!
You need to be in go module mode to get code of a specific version, since in addition to downloading the code, the version is recorded in the go module file.
The easiest way to do this would be to create an empty directory, run go mod init, which will create a go.mod file.
Then, you can run go get golang.org/x/lint/golint#v0.0.0-20181217174547-8f45f776aaf1, which will add golint at that version to your go.mod file. You can then run go install golang.org/x/lint/golint from within that directory, which will install golint at the version specified into your $GOBIN directory (which defaults to $GOPATH/bin).
I'm developing Golang project and using TravisCI. As dependency tool, Godeps is used.
After running test by git push, something error was happened as below.
# command-line-arguments
cmd/proj/main_test.go:6:2: cannot find package
"command-line-/vendor/github.com/xxxxx/xxxxx/abc" in any of:
/home/travis/.gimme/versions/go1.6.linux.amd64/src/command-line-/vendor/github.com/xxxxx/xxxxx/xxx
Why it can't find package?
As build log, it seems to work well by go get command.
My travis.yml is here.
language: go
sudo: false
go:
- 1.6
- tip
services:
- redis-server
env:
global:
- secure: "xxxxx"
script:
- go fmt ./...
- go vet $(go list ./... | grep -v /vendor/)
- go test -v cmd/xxxx/*.go -xxxx ${XXXXX}
before_install:
- go get github.com/tools/godep
branches:
only:
- master
tip of go version is OK.
But 1.6 or 1.5 version can't run well.
How can I manage that situation?
The way Go 1.6 manages dependencies is different than Go 1.5 and previous versions.
1.6 introduces the /vendor folder. Whenever you import a dependency, if the library exists in /vendor, then the library is loaded.
The behavior was introduced in 1.5, but in that version it was experimental. It means that you need to enable it using the GO15VENDOREXPERIMENT=1 environment variable.
If you only need to provide support for 1.5 and 1.6, then simply add the variable to Travis when building 1.5 projects.
If you need to extend support also for versions before 1.5, then it's a little bit more complicated.