Well ,I sooooo flesh for the Golang . And I get a mission to recompile the Golang 's runtime via this blog.
One way is to change this default number in the GO runtime (GCC-GO or GC) and recompile the runtime. In proc.go, you can change the line sched.maxmcount = 10000 to a number that is appropriate.
First: recompile the whole golang.
I follow this Installing Go from source ,and execute this cmd：
./all.bash
Output is :
Building Go bootstrap tool.
cmd/dist
import cycle not allowed
package cmd/dist
imports bytes
imports errors
imports runtime
imports runtime/internal/atomic
imports unsafe
imports runtime
It seems everything work well, but while I check about the go cmd，it's the same. Also ,I can't find any change to bin or pkg dir.
Then ,try to build pkg
go install src/runtime
Also, it doesn't come out any error and I can't find any target build.
I have no any idea how to do it :(
Any suggestion well so appresiate !
You install packages by their import path, so you don't use the src/ prefix.
To recompile the runtime package, use:
$ go install -a -v runtime
runtime/internal/sys
runtime/internal/atomic
runtime
Related
go version go1.11.4 darwin/amd64
GOPATH has been unset but was previously set to $HOME/Development/go
Project path is under $HOME/code/
I’m able to successfully (no errors at least) install the go-sql-driver/mysql package using the command
go get github.com/go-sql-driver/mysql#v1
When I include a reference to that package in an import statement
import(
_ "github.com/go-sql-driver/mysql")
in my code I see the error
could not import github.com/go-sql-driver/mysql (can’t find import:
“github.com/go-sql-driver/mysql”)
I have run go mod init in my project root and it creates a go.mod file. When I run the go get command I see a require statement added to that file for the package. But it seems the files for the package get installed in the default $HOME/go directory (since I've unset GOPATH).
Should I be doing things differently so that my import statement can find the newly installed package? Using modules shouldn't all the packages be installed in the project path somewhere?
Should I be doing things differently so that my import statement can find the newly installed package?
No. With modules there is no need to install the packages upfront at all.
Using modules shouldn't all the packages be installed in the project path somewhere?
No. They get downloaded somewhere in some format and used from that location but they are not "installed" like in the old GOPATH variant of go get.
Show output of go env and what go mod vendor produces.
I'm pretty sure I was doing things wrong. I was able to resolve this after referencing the following closely the steps documented at golang modules wiki. The summary is that there is no need to "install" a package via 'go get'. Instead simply make sure your project is initialized to use modules using the 'go mod init' command and then include the package name in an import statement. The next build event will pull down the package and all its dependencies.
I've recently started with Go 1.11 and love the modules. Apart from runtime dependencies I need to work with go modules during the build, e.g. during go generate.
How can I install a specific build dependency (e.g. github.com/aprice/embed/cmd/embed) and run that specific tool from which folder? Is go get the right tool for doing so?
If you get an error
I was not seeing the dependency that I wanted added to the go.mod and I was getting this error:
internal/tools/tools.go:6:5: import "github.com/UnnoTed/fileb0x" is a program, not an importable package
(fileb0x is the thing I'm trying to add)
I'm not 100% clear on the sequence of events that fixed it, but I did all of these things:
Using a "tools" package
I made a tools directory:
mkdir -p internal/tools
I put the tools package inside of it (as mentioned above):
internal/tools/tools.go:
// +build tools
package tools
import (
_ "github.com/UnnoTed/fileb0x"
)
Note that the tag is mostly not important. You could use foo:
// +build foo
However, you cannot use ignore. That's a special predefined tag.
// +build ignore
// NO NO NO NO NO
// `ignore` is a special keyword which (surprise) will cause
// the file to be ignore, even for dependencies
Updating go.mod
The best way is probably to run go mod tidy:
go mod tidy
However, before I did that I ran a number of commands trying to figure out which one would cause it to go into go.mod:
go install github.com/UnnoTed/fileb0x # didn't seem to do the trick
go get
go generate ./...
go build ./...
go install ./...
go mod vendor
Later I did a git reset and rm -rf ~/go/pkg/mod; mkdir ~/go/pkg/mod and found that go mod tidy did well enough on its own.
vendoring
In order to actually take advantage of the modules cache in a project you need to copy-in the source code
go mod vendor
That will grab all dependencies from go.mod
You also need to change nearly all of your go commands to use -mod=vendor in any Makefiles, Dockerfiles or other scripts.
go fmt -mod=vendor ./... # has a bug slated to be fixed in go1.15
go generate -mod=vendor ./...
go build -mod=vendor ./...
That includes go build, go get, go install, and any go run called by go generate (and even the go generate itself)
//go:generate go run -mod=vendor github.com/UnnoTed/fileb0x b0x.toml
package main
// ...
https://github.com/golang/go/issues/25922 proved helpful for me, especially
when using build-only dependencies with modules the main point is version selection (not installing these!)
To avoid installing you can modify your //go:generate directive to something like:
//go:generate go run golang.org/x/tools/cmd/stringer ARGS
There is also the best practices repo: https://github.com/go-modules-by-example/index/blob/master/010_tools/README.md
The convention is to add a file named "tools.go" that is guarded by a build constraint and imports all required tools:
// +build tools
package tools
import (
_ "github.com/aprice/embed/cmd/embed"
)
https://github.com/golang/go/issues/25922#issuecomment-412992431
The tools are then installed as usual in one of
$GOBIN
$GOPATH/bin
$HOME/go/bin
You may also want to follow https://github.com/golang/go/issues/27653, which discusses future explicit support for tools.
tools.go is a great solution if you're building an app or service. But if you're building a library, tools.go still leaks dependencies to things consuming your library (your tools are still there as indirect dependencies, and go mod tidy will pull them in since it considers every possible target). That's not the end of the world since those modules never end up in the actual built binaries of the consumer, but it's still messy.
https://github.com/myitcv/gobin/issues/44 is probably the most promising approach to fixing this long term, but short term I've used a combination of the "internal module" approach explained there along with https://github.com/izumin5210/gex.
First, I install gex globally:
GO111MODULE=off go get github.com/izumin5210/gex/cmd/gex
Then before actually using gex I create a structure like this:
myproject/
\
- go.mod: module github.com/ysamlan/myproject
\
internal/
\
tools/
- go.mod: module github.com/ysamlan/myproject/tools
To install a build-only tool I just cd internal/tools and run gex --add (sometool), which puts that tool in internal/tools/bin. CI scripts and other folks that want to build my stuff locally just need to run cd internal/tools && gex --build to reliably and reproducibly populate the tool binaries, but the top-level go.mod is unchanged.
The key piece there is creating that internal/tools/go.mod file with a different module path than the one the root project uses, and then only running gex from that directory.
I have a stripped down environment, where I want to use go at a custom path.
printenv gives me:
GOOS=linux
GOROOT=/mygo
GOHOSTOS=linux
GOARCH=amd64
TMPDIR=/mytmp
GOHOSTARCH=amd64
GOPATH=/mysrcs
PWD=/home/andreas
Now if I try to compile go code, it fails to find the stdlib:
could not import fmt (cannot find package "fmt" in any of:
/mygo/src/fmt (from $GOROOT)
If I do find /mygo | grep fmt, I get:
/mygo/pkg/linux_amd64/fmt.a
When I use the system go (normal bash environment), it works fine. What implicit dependencies does go need to find the stdlib packages?
Thanks to #JimB, I managed to get it working.
I indeed want binary-only packaging of stdlib.
Discussion online is that $GOROOT/pkg is a valid use-case for binary distribution, while $GOPATH/pkg might get deprecated soonish, so beware.
If you want to provide binary-only packages, https://github.com/tcnksm/go-binary-only-package shows how to create (annotated) src directory structure, in order for go to stop searching for source files.
I created a simple lazy package manager for go.
I published it at https://github.com/kfirufk/glpm.
when I execute go get github.com/kfirufk/glpm I get no errors, but it compiles it as a module since the resulted pkg content at $GOPATH/pkg/darwin_amd64/github.com/kfirufkis glpm.a.
I want it to be compiled as an executable. what am I missing?
thanks
To get your project building as an executable, you need to have:
All of the buildable Go files as part of the package main, and
Define a main function to be the entry point for your program
However, if your package can also be used as a library, a common pattern is to have your executable stored in $PACKAGE/cmd/$EXECUTABLE_NAME. This would mean your package executable would be fetched using:
go get -u github.com/kfirufk/glpm/cmd/glpm
Is it possible to install a Golang package system-wide and not need the source code afterwards in order to compile programs that use it?
More particularly, having just the pkg/linux_amd64_dynlink/ directory with, for example, libstringutil.so stringutil.a and stringutil.shlibname files, how can I compile a simple hello.go that imports stringutil?