Till Go 1.4.2 when i run go install after running go build, i could find binary file in my current folder. Hence following Linux command was working
$ go build && go install && ./executable
But after installing go 1.5, when i run same command i get,
-bash: ./executable: No such file or directory
and when i checked, there is no executable to find. Did go install behavior changed in Go 1.5?
Yes, the behaviour has changed in Go 1.5:
If 'go install' (with no arguments, meaning the current directory) succeeds, remove the executable written by 'go build', if present. This avoids leaving a stale binary behind during a sequence like:
go build
<test, mostly works, make small change>
go install
Before this CL, the current directory still has the stale binary from 'go build'. If $PATH contains dot, running the name of the program will find this stale binary instead of the new, installed one.
I can't find anything mentioning that in the release notes though. Might be a documentation issue.
It seems like the solution is to use the binary that go install has produced.
EDIT: Here is the issue on the Go issue tracker if you want to follow on updates. Should be fixed by 1.5.1.
Related
The go clean -i command that is ran inside some project deletes an executable file of that particular project that was previously installed by go install command. How to delete everything installed by the go install commands that were ran from several different projects? Is there some single go command that can do that?
TL;DR
Delete the binary like any other file.
The "install" term means place (something) in a new position ready for use.
Therefore, Go builds a single-file binary and places it in another directory ($GOPATH/bin). It is useful when you add the Go binary directory into the environment variable to call the program.
There's no auxiliary flag such as go clean -bincache to remove all binaries installed by Go 1.16.4.
However, at the current version of GoLang (1.16.4), the right way to remove (or "uninstall" as you said) any installed binary is solely to delete it, like any other file despite you feel it sounds awkward.
Im new to go and I have been unable to find any thing online for my issue.
I have downloaded this code https://github.com/hashicorp/http-echo and I would like to set it up so I can run this command.
$ http-echo -listen=:8080 -text="hello world"
I have been getting quite a few different path issues.
Currently I have the code sitting in this directory.
/Users/jon/go/src/github.com/hashicorp
When I try and install it I get this error
$ go install http-echo
can't load package: /usr/local/go/src/http-echo/handlers.go:9:2: non-standard import "github.com/hashicorp/http-echo/version" in standard package "http-echo"
Where should I keep go projects on an OSX computer, and how do I get this to install or compile?
The code currently seems to be in /usr/local/go/src/http-echo. Packages should always reside in the directory $GOPATH/src/package-name, e.g.: $GOPATH/src/github.com/hashicorp/http-echo. (unless you're using go modules).
It should work if you move the source to the correct path (/Users/jon/go/src/github.com/hashicorp/http-echo). Then execute:
go install github.com/hashicorp/http-echo
Even easier would be to use go get to download the package in the first place. Simply run the following command from any directory:
go get github.com/hashicorp/http-echo
And http-echo is automagically installed.
If you still get an error after this, make sure $GOPATH/bin is in your $PATH.
I know that this should probably be very easy, and I have looked into the read me files and other files in cgdb like INSTALL that talk about isntalling cgdb. I was trying to install cgdb and the instructions said:
$ ./configure --prefix=/usr/local
$ make
$ sudo make install
However, there is no such file inside of the file I got from running the git clone command. i.e. from running:
$ git clone git://github.com/cgdb/cgdb.git
I went inside that file to see the installation instructions and it says the following:
Basic Installation
==================
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using `csh' on an old version of System V, you might need to type
`sh ./configure' instead to prevent `csh' from trying to execute
`configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Optionally, type `make check' to run any self-tests that come with
the package.
4. Type `make install' to install the programs and any data files and
documentation.
5. You can remove the program binaries and object files from the
source code directory by typing `make clean'. To also remove the
files that `configure' created (so you can compile the package for
a different kind of computer), type `make distclean'. There is
also a `make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
and there is more I didn't paste.
The part that confuses me is the following paragraph:
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
does it mean I should run ./configure.in? I am honeslty a little scared of running it because I need to run it in as sudo plus, that file doesn't even exit in the code I got from git clone. This is what I do have in that directory:
➜ cgdb git:(master) ls
AUTHORS Makefile.am autogen.sh doc roadmap.txt
COPYING NEWS autorelease.sh indent.sh test
ChangeLog README cgdb lib
FAQ README.md config packages
INSTALL TODO configure.init release-todo.txt
➜ cgdb git:(master)
I did grep for config or config.in in that directory and it didn't yield anything useful.
I have also tried brew installing it but I ran into problems. When I cgdb the file and hit run it frozen at a print statment instead of moving on to the next command prompt for gdb as in (gdb). Anyone knows whats up? Is it because I am using go source file?
What have people done to have cgdb working on a mac?
Неу, yeah, the git source for cgdb doesn't come with the configure script pre-built. (The official release distributions do, however.)
If you have the right tools installed, you can fix this by running:
./autogen.sh
This will generate the configure script, and then you can install it as you would any other autoconf-based source package.
Forget about all that aggro with configuration and dependency libraries; install MacPorts and do:
$ sudo port install cgdb
They have 0.6.7 at the time of writing.
What worked for me was doing:
brew install cgdb
However, for me that was not enough to get it going. I needed to sudo it for it to run:
sudo cgdb
I would have never guessed I needed to sudo it...I figured it out because it was throwing me the error talked about in the following question:
gdb fails with "Unable to find Mach task port for process-id" error
After upgrading from Go 1.2.1 to 1.3 (Windows 7 64 bit) "go build" execution time has increased from around 4 to over 45 seconds. There were no other changes except the go version update. Switching off the virus scanner seems to have no effect. Any clues?
You probably have dependencies that are being recompiled each time. Try go install -a mypackage to rebuild all dependencies.
Removing $GOPATH/pkg also helps to ensure you don't have old object files around.
Building with the -x flag will show you if the toolchain is finding incompatible versions.
I have the exact same problem, running this command solves it:
go get -u -v github.com/mattn/go-sqlite3
Another tip: http://kokizzu.blogspot.co.id/2016/06/solution-for-golang-slow-compile.html
Using go1.6,
Simply run go build -i.
It will compile all the dependencies and store them at $GOPATH/pkg/*/* as .a files.
Later when you run go run main.go, everything is much faster.
What s really great is that if you use vendored dependencies (IE: a vendor folder in your project), deps are built appropriately within $GOPATH/pkg/**/yourproject/vendor/**
So you don t have to go get install/get/whatever and have a mix of vendor / global dependencies.
I suspect you got to re-build .a files after deps update (glide update or smthg like this), but i did not test that yet.
After Go 1.10, you'd just need to type go build. You'd not need to type: go build -i.
From the draft Go 1.10 document, here.
Build & Install
The go build command now detects out-of-date packages purely based on the content of source files, specified build flags, and metadata stored in the compiled packages. Modification times are no longer consulted or relevant. The old advice to add -a to force a rebuild in cases where the modification times were misleading for one reason or another (for example, changes in build flags) is no longer necessary: builds now always detect when packages must be rebuilt. (If you observe otherwise, please file a bug.)
...
The go build command now maintains a cache of recently built packages, separate from the installed packages in $GOROOT/pkg or $GOPATH/pkg. The effect of the cache should be to speed builds that do not explicitly install packages or when switching between different copies of source code (for example, when changing back and forth between different branches in a version control system). The old advice to add the -i flag for speed, as in go build -i or go test -i, is no longer necessary: builds run just as fast without -i. For more details, see go help cache.
I just experienced the same problem - updating from 1.4 to 1.5. It seems that the olds versions are somehow incompatible or are being rebuild every time as go build -x shows. Executing go get -v invalidates all packages or refetches them, I am not quite sure and go build -x shows quite less output.
You can build sqlite3 like this:
cd ./vendor/github.com/mattn/go-sqlite3/
go install
After that your project will b built much faster.
If you try as all other said but still not work, I suggest removing the directory of $GOPATH such as :
sudo rm -rf $GOPATH
cd yourproject
go get -d
go get -u -v github.com/mattn/go-sqlite3
Every time I try to compile my program after (this morning) upgrading go from 1.1.1 to 1.1.2 (on Windows 7 64 bits), I get error message like:
C:\Users\VonC\prog\go\src\github.com\spf13\hugo>go build -o hugo.exe main.go
# github.com/spf13/hugo/hugolib
hugolib\page.go:23: import C:\Users\VonC\prog\go\pkg\windows_amd64/github.com/emicklei/hopwatch.a:
object is [windows amd64 go1.1.1 X:none]
expected [windows amd64 go1.1.2 X:none]
I tried a go clean -r, but the error message persists?
What is the right clean command to use?
Actual solution:
I reproduced the issue with:
calling the 1.1.2 go.exe directly (I didn't have %GOROOT%\bin in my path)
with GOROOT pointing to the previous 1.1.1 installation folder (I kept go 1.1.1 and 1.1.2 installed in separated folders).
If you are sticking with the default go setup (ie: one C:\go installation directory, and %GOROOT%\bin in your PATH), you won't see this error.
But if you do see this error:
make sure %GOROOT% is consistent with the go.exe you are calling
go install -a as explained below. The go clean mentioned below won't be necessary.
As jnml comments:
the Go build system is supposed to figure out any obsolete stuff in $GOPATH/pkg and (transitively) rebuild it on demand.
Original solution:
In the "Remove object files" section of "Command go" page, I missed the go clean -i option:
-i
The -i flag causes clean to remove the corresponding installed archive or binary (what 'go install' would create).
And those .a file (like hopwatch.a) are precisely what go install generates for libraries (in Windows).
So the full clean command, to make sure go rebuild everything, would be:
cd C:\Users\VonC\prog\go\src\github.com\spf13\hugo
go clean -r -i
go install -a
That will rebuild and install everything, including all dependent packages.
The -a is actually a build option, which forces rebuilding of packages that are already up-to-date.
As usual, go clean -r -n would show you what would be cleaned (-n: preview option).
It doesn't hurt to be sure of what will be deleted... before actually deleting anything.