Problem
I haven't been able to find a solution to this by looking at related questions. I can't tell what makes my Go environment different from the canonical setup.
go env returns
GOROOT="/usr/lib/go"
GOBIN=""
GOARCH="386"
GOCHAR="8"
GOOS="linux"
GOEXE=""
GOHOSTARCH="386"
GOHOSTOS="linux"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_386"
GOGCCFLAGS="-g -O2 -fPIC -m32 -pthread"
CGO_ENABLED="1"
tree $GOPATH returns
/home/USER/go
├── bin
├── pkg
│ └── linux_386
│ └── bitbucket.org
│ └── USER-NAME
│ └── PROJECT
│ └── my_package.a
└── src
└── bitbucket.org
└── USER-NAME
└── PROJECT
├── main
│ ├── main.go
└── my_package
└── my_package.go
(ALL-CAPS are substitutions)
main.go contains
package main
import (
"bitbucket.org/USER-NAME/PROJECT/my_package"
)
func main() {
my_package.Foo()
}
Calling go build in the main directory returns import "my_package": cannot find package
Volker pointed out that go env should have returned a GOPATH entry as well. The source of the env command corroborates that. However, running echo $GOPATH in bash or os.Getenv("GOPATH") in Go both return \home\USER\go. I'm not sure why the same isn't returned by go env.
Solution
I was running Go 1.0 when I was having this issue. The problem disappeared when I upgraded to Go 1.2.1.
You have a directory called main. This won't work. Change it.
Structure it like $GOPATH/src/bitbucket.com/youruser name/yourpackagename/{main.go, otherthing.go, otherpackagedirectory}.
"package main" doesn't have to be in it's own sub folder: it inherits the name of your Bitbucket project (username/myprojectname).
You did not set (or export) GOPATH. GOPATH Is much more important than GOROOT (at least in newe Go versions).
Related
I am creating 3 separate go projects: ace, aces-client and a library shared by both projects aceslib. I am having trouble including the shared library according to the go-documentation (https://golang.org/doc/code.html#Library)
all go files in aceslib share the package-name aceslib. I am including the library in ace and aces-client with import lib "aceslib". I can build the library with go build and it gets installed with go install, in the directory listing one can see that the file go/pkg/windows_amd64/aceslib.a gets created.
But when I try to build ace or ace-client go complains:
$ go build
build ace: cannot load aceslib: cannot find module providing package aceslib
My go setup:
$ go version
go version go1.12.9 windows/amd64
$ go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Yulivee\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\Yulivee\go
set GOPROXY=
set GORACE=
set GOROOT=c:\go
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\Yulivee\go\src\ace\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Yulivee\AppData\Local\Temp\go-build024649150=/tmp/go-build -gno-record-gcc-switches
Directory Structure:
.
├── bin
│ ├── ace-client.exe
│ └── ace.exe
├── pkg
│ ├── mod
│ │ ├── cache
│ │ └── golang.org
│ └── windows_amd64
│ ├── ace
│ ├── aceslib.a
│ └── golang.org
└── src
├── ace
│ ├── README.md
│ ├── go.mod
│ ├── go.sum
│ └── main.go
├── ace-client
│ └── main.go
├── aceslib
│ ├── README.md
│ ├── crypto.go
│ ├── go.mod
│ └── utils.go
What am I missing?
Things I have tried, that did not help and lead to the same error:
$ go clean -i -x -cache -modcache
$ chmod 755 go/pkg/windows_amd64/aceslib.a
$ go get
build ace: cannot load aceslib: cannot find module providing package aceslib
$ rm -rf go/pkg/*
The directory structure and package names are a bit off - it should be a URL to your project's repo, like every other import that isn't from the stdlib. If you have no repo and want to use local references you'll need to add a replace directive to ace/go.mod like so:
replace aceslib => ../aceslib
As documented in the Modules docs.
IIRC, package names without directories are reserved for stdlib packages. So, you should first push the source tree down at least a level so you can access it by "dir/package".
Next, do you really want to treat these packages as separate modules? You have separate mod files under ace and aceslib packages. You may combine them under one module with a single go.mod at the project root and make life easier for yourself. That way you don't need redirects, etc.
You also have to include the modules with their directories:
import lib "dir/aceslib"
Running a go run main.go I get a strange error message:
danilo#lm ~/godev/src/quick $ go run main.go
command-line-arguments
/usr/lib/go-1.6/pkg/tool/linux_amd64/link: cannot open file /usr/lib/go-1.6/pkg/linux_amd64/github.com/valyala/quicktemplate.a: open /usr/lib/go-1.6/pkg/linux_amd64/github.com/valyala/quicktemplate.a: no such file or directory`
Here is my environment:
Linux Mint 18
GOLANG ENV:
danilo#lm ~/godev/src/quick $ go env
GOARCH="amd64"
GOBIN="/home/danilo/godev/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/danilo/godev"
GORACE=""
GOROOT="/usr/lib/go-1.6"
GOTOOLDIR="/usr/lib/go-1.6/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"
My $GOPATH tree:
.(godev)
├── bin
│ └── qtc
├── pkg
│ └── linux_amd64
│ └── github.com
│ └── valyala
│ ├── bytebufferpool.a
│ └── quicktemplate.a
└── src
├── github.com
│ └── valyala
│ ├── bytebufferpool
│ │ ├── ...
│ └── quicktemplate
│ ├── ...
└── quick
├── main.go
└── templates
├── hello.qtpl
└── hello.qtpl.go
It seems like to miss the pkg folder in my workspace where the static libraries are stored!
Am I right?
Sorry, I solved. The main.go code was:
package main
import (
"fmt"
"./templates"
)
func main() {
fmt.Printf("%s\n", templates.Hello("Foo"))
fmt.Printf("%s\n", templates.Hello("Bar"))
}
so I missed to use absolute path in the import section:
package main
import (
"fmt"
"quick/templates"
)
func main() {
fmt.Printf("%s\n", templates.Hello("Foo"))
fmt.Printf("%s\n", templates.Hello("Bar"))
}
I am trying to use a shared library in go-lang, I am following this blog post: http://blog.ralch.com/tutorial/golang-sharing-libraries/
But when I hit build I get back an error:
simo#simo:~/gopath$ go build -linkshared -o app effe/prova
src/effe/prova/prova.go:3:8: cannot find package "libmath" in any of:
/usr/local/go/src/libmath (from $GOROOT)
/home/simo/gopath/src/libmath (from $GOPATH)
I am pretty new to go, so I will show also my environment...
simo#simo:~/gopath$ pwd
/home/simo/gopath
simo#simo:~/gopath$ echo $GOPATH
/home/simo/gopath
simo#simo:~/gopath$ tree
.
├── pkg
│ └── linux_amd64_dynlink
│ ├── effe
│ │ ├── libmath.a
│ │ └── libmath.shlibname
│ └── libeffe-libmath.so
└── src
└── effe
├── libmath
│ └── libmath.go
└── prova
└── prova.go
7 directories, 5 files
simo#simo:~/gopath$ cat src/effe/libmath/libmath.go
// filename: libmath.go
package libmath
func Sum(x, y int) int {
return x + y
}
simo#simo:~/gopath$ cat src/effe/prova/prova.go
package main
import "libmath"
import "fmt"
func main() {
fmt.Printf("5 op 10 => %d", libmath.Sum(5, 10))
}
simo#simo:~/gopath$ go install -buildmode=shared -linkshared effe/libmath
simo#simo:~/gopath$ go build -linkshared -o app effe/prova
src/effe/prova/prova.go:3:8: cannot find package "libmath" in any of:
/usr/local/go/src/libmath (from $GOROOT)
/home/simo/gopath/src/libmath (from $GOPATH)
What am I doing wrong ?
The import path for "libmath" is "effe/libmath".
Try to get your build working in the standard build mode before experimenting with more complicated build and execution modes.
I am using go version go1.5.1 linux/amd64 on debian 8.2 3.16.0-4-amd64. I installed golang using https://golang.org/doc/install.
This is what i put in my ~/.profile file
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:/home/shivams/go/bin
Running go env on my machine is giving this output
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/shivams/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT=""
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"
Directory structure inside /home/shivams/go is {pkg,src,bin}. Inside src directory it is like test/hello.go.
If i am in src dir and run go run test/hello.go it is running perfectly. Also if i run go build test/hello.go it will create one executable hello file in same directory.
But if i try to run go install test/hello.go then i get this error
go install: no install location for .go files listed on command line (GOBIN not set). If i set GOBIN explicitly then i am not able to see this error.
From what i read my understanding is that if GOPATH is set there is no need to set GOBIN variable.
Am i missing anything here? This is the first time i am trying go and not able to get this working.
As #JimB states, install is a command designed for packages. Just to give you a clear example, here is what I get when I run the go env command.
GOARCH="amd64"
GOBIN="/Users/quazinafiulislam/Code/go/ogolang/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/quazinafiulislam/Code/go/ogolang"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.5.1/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.5.1/libexec/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT=""
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"
You will see that the GOPATH is set to my project root, ~/Code/go/ogolang. Now, lets see whats inside my project root.
.
├── bin
├── pkg
│ └── darwin_amd64
└── src
├── bitbucket.org
├── github.com
├── golang.org
├── words
└── wordtest
As you can see I have a couple of packages. One of them is wordtest. I can use a go install on the words or wordtest packages. So, lets run go install words and see what happens to the directory.
.
├── bin
│ └── words
├── pkg
│ └── darwin_amd64
└── src
├── bitbucket.org
├── github.com
├── golang.org
├── words
└── wordtest
Now, we can see that we have a words binary created for us(inside the bin directory), and we can run it by invoking ./bin/words.
According to Games Brainiac go install work on packages is correct. But let me add some details into it regarding creating packages using go install in main directory.
.
├── bin
│ └── app
├── pkg
│ └── linux_amd64
| └── user
| └── handlers.a
└── src
├── bitbucket.org
├── github.com
└── user
└── app
├── main.go
└── handlers
└──handlers.go
Have a look at above directory structure, I have created a package in a folder handlers having source file handlers.go .And I wants to build that package, I will run go build inside handlers folder which just show our file has no compilation errors and returns nothing in that case.
To build a package with main file we need to run go install inside app folder. This will create handlers.a package object inside $GOPATH/pkg and executable file inside $GOPATH/bin with name of folder (app in this case) in which we have main.go file using package main.
I am trying to build and install a SWIG-generated perl API on OS X 10.10.2. (It's for the FreeLing 3.1 language analysis toolkit.) I have generated and compiled the SWIG files, producing freeling.so.
But when I try to use freeling in a perl script, I get the error:
Can't find 'boot_freeling' symbol in /usr/local/lib/libfreeling.dylib at freeling.pm line 11.
But boot_freeling should be defined in the SWIG-generated freeling.so, not in libfreeling.dylib (the FreeLing package lib). (nm -U confirms this: _boot_freeling is defined in freeling.so; I'm assuming the leading underscore is just part of the object file format.)
I have made sure that freeling.so comes before libfreeling.dylib in LD_LIBRARY_PATH. I've also tried unshifting the path to freeling.so onto #DynaLoader::dl_library_path.
I suspect this is not a path problem, but something about building for OS X. In the past, I have built this on Ubuntu and it works fine. I have tweaked the gcc options (-bundle instead of -shared).
Additional info:
perl -V:dlext => dlext='bundle';
Building SOso-0.01.patch.txt produces:
blib
├── blib/arch
│ └── blib/arch/auto
│ └── blib/arch/auto/SOso
│ └── blib/arch/auto/SOso/SOso.bundle
├── blib/bin
├── blib/lib
│ ├── blib/lib/SOso.pm
│ └── blib/lib/auto
│ └── blib/lib/auto/SOso
├── blib/man1
├── blib/man3
└── blib/script
Makefile target:
freeling.bundle: freeling_perlAPI.cxx
g++ -v -bundle -o freeling.bundle freeling_perlAPI.cxx -lfreeling -lperl -lboost_system -I $(FREELINGDIR)/include -I $(BOOSTDIR)/include -I $(ICU4CDIR)/include -L $(FREELINGDIR)/libfreeling -I $(PERLDIR)/CORE -L $(LIBDIR) -L $(BOOSTDIR)/lib -L $(PERLDIR)/CORE -fPIC
Ok, promoting to answer :)
What do you get for perl -V:dlext ?
When you compile this module SOso-0.01.patch.txt what files are created in blib?
Well :) if your os/perl is configured to look for a freeling.bundle, I don't think its going to try to look at freeling.so .... so I'd try to do something about that ... rename the file to use the dlext