I made a second development on levigo, when I finished it and try to install it on my system with the following command:
go install github.com/AndreMouche/levigo/
it reports the following error:
# github.com/AndreMouche/levigo
/home/fun/software/go/go/pkg/tool/linux_amd64/6c: unknown flag -FVw
Does anybody know how to fix it?
Your go command probably differs from your go tool chain.
Check if the right version of the go tool is in the PATH of your shell or try reinstalling go.
The go tool calls tools like the compiler (e.g. 6g) and the linker. If the go tool version
does not correspond with the version of these tools, said tools may get called with parameters
they don't yet know or they don't know anymore.
Check the version using these commands:
$ go version
$ go tool 6g -V
They both should report the same version string.
See this and this post for related problems.
Related
In VSCode, I am trying to rename a variable using F2. This seems to run the gorename tool, but fails every time without explicit error. It simply displays:
/home/oops/dev/mtg-tracker/mtg-tracker-server/handlers>Finished running tool: /home/oops/dev/go/bin/golint
/home/oops/dev/mtg-tracker/mtg-tracker-server/handlers>Finished running tool: /usr/local/go/bin/go build -i -o /tmp/vscode-goVw9yJs/go-code-check .
/home/oops/dev/mtg-tracker/mtg-tracker-server/handlers>Finished running tool: /usr/local/go/bin/go vet ./...
Rename failed
I've looked into similar issues and it seems to normally come with an error such as an invalid GOROOT or incorrect package naming, but I see no such error here and I haven't been able to find any further info.
I also saw that someone fixed this by updating gorename, which I tried looking into but have not been able to figure out how to do.
Expected result: VSCode actually renames my variable.
Actual result: The rename fails and it stays the same.
Note there is an issue 24661 dedicated to follow the tools and their updates, for command-line or VSCode usage.
That issue just included:
gorename will no longer be supported as gopls already implemented renaming functionality.
See issue 27571, which refers to issue 32875.
In the meantime, pending full support of gorename, I am using saibing/tools which does produced an "extended" version of gopls, with rename support.
And which is working just fine in VSCode.
Update Q4 2019 (Nov.): issue 32875 is now closed, gopls has released a 0.2.0 and those errors should be fixed.
A full rename support is still there: CL 194878
Remains CL 207579: This change adds command line support for prepare_rename.
Update Sept. 2020:
As commented and in CL 255053 (for go bundle), a lot of the tools in this list have been replaced by gopls as well.
I am using JetBrains GoLand and I am trying to debug my go file and I am getting the following error:
decoding dwarf section info at offset 0x0: too short
I tried to find an answer here at StackOverflow but unfortunately, I didn't get any solution.
GoLand ships with a bundled version of Delve. Update to 2018.2.2 and it should work. If you need to do remote debugging, then you need to update your Delve installation on/for the target machine as well (make sure you compile it with Go 1.11).
Edit:
There are two more possible cases where this issue can appear:
the application was compiled with all the debugging flags turned off and the additional debugging information stripped
the application uses the standard library "plugin" package, which is known to cause an issue in the Go compiler. This will be fixed in Go 1.12.
I would like to share my experience here too as it may be helpful for community, I made it works by doing the following:
Update Goland to 18.3
Also, in case if you have Mac, you should run xcode-select --install
In case if you had delv already installed inside GOPATH/bin, remove it and re-install it again by following instructions here
For my Mac the problem is related to the dlv package as installed by Golang plugin.
Install delv and,
check the path of dlv as executed by IntelliJ (in the console).
Go to this directory
($HOME//Library/Application Support/IntelliJIdea2017.3/intellij-go/lib/dlv/mac)
and rename dlv to any other name. Get the right dlv executable by using
which dlv (/usr/local/Cellar/go/1.11.1/libexec/bin/dlv for my computer)
and add a symbolic link
(ln -s /usr/local/Cellar/go/1.11.1/libexec/bin/dlv dlv).
After hours of effort, I was able to find the issue. It was due to Golang Plugin which is deprecated and was not compatible with IntelliJ IDEA 2018.2.2 (Ultimate Edition).
I uninstalled the plugin and reinstall the IntelliJ.
Hope this also helps to above solutions.
Trying
devtools::install_github("Rexamine/stringi")
and getting error:
Could not find build tools necessary to build stringi
I see several people have had this error but the solutions haven't worked for me. I reinstalled xcode because the command line tools seemed to be the problem for other people. Checked the paths for R and RStudio, I can open both fine (from the terminal as well). Don't think this is an Rtools issue but I can't figure out where the problem is. Has anyone had any luck with this particular devtools error?
Running OSX 10.11.6, RStudio Version 0.99.896, R 3.2.1 GUI 1.66 Mavericks build (6956), XCode Version 7.3.1 (7D1014).
You can try running
/usr/bin/clang --version
If command line tools are installed, this should just report the version of clang installed; otherwise, you'll be prompted to install Xcode + Command Line Tools. (This is just a simple way of ensuring command line tools indeed are installed)
If you run
devtools::install_github("Rexamine/stringi")
in a plain R console, outside of RStudio, what do you see? Can you update your post with the errors (if any) printed to the console?
You might also try updating RStudio to the preview release (https://www.rstudio.com/products/rstudio/download/preview/) to see if that helps.
It seems like this is likely a bug in RStudio's build tools detection; you might try explicitly disabling it with:
options(buildtools.check = function(action) TRUE)
This should ensure that devtools doesn't try to call RStudio's build tools detection code and just assume that everything is available.
I want to update the distribution version of glibc and in order to keep the distribution settings, paths, ... I need the original used configure command line options.
Running gcc -v displays under Configured with: the configure command line options.
Is there something similar for glibc?
Unlike GCC, GLIBC doesn't record its configure options anywhere, so the direct answer is no.
However, if you download the source package for your current version of glibc and build it (precise commands vary between distributions), then you'll know how your current version has been configured.
P.S. Upgrading GLIBC incorrectly is one of the easiest ways to render your system unbootable. Make sure you have a suitable system recovery disk, and know how to use it before attempting this upgrade.
I recently started trying go to program some web based applications. At first, everything went fine, until I wanted to cross compile a binary for a different platform. I'm running MacOS and I wanted to compile a binary for linux, so I changed GOOS to linux and GOARCH to amd64. Since then, I always get the error message
go tool: no such tool "compile"
I'm using GoClipse, but running the compile manually by
go install hello.go
I get the same error. When changing back to compiling for darwin architecture, I get the same error now, so basically I'm totally unable to compile any code written in Go at the moment.
I installed it via the binary packages provided by google. In the end I actually got it back to work by just reinstalling it. Sometimes I'm just blind to the easy solution.
After that, I succeeded in cross compiling for linux machine after compiling the necessary cross-compilers by running env GOOS=linux GOARCH=arm GOROOT_BOOTSTRAP=/usr/local/go ./make.bash --no-clean from the Go sources directory.
Thanks for all you efforts, sorry to have kept you busy on such a simple matter.
You have the wrong x64 or x386 package installed most likely. I had 32 installed running 64 bit. Reinstall fixed. Good luck.
You might be able to get away with that if you install Go 1.5, however if you use anything that depends on cgo, you will have to install a cross-compiler linker or install Linux on a virtual machine to be able to cross compile for Linux.
In my case is due to the fact that GOPATH and GOROOT are not set correctly, maybe you can check go env. Here is a discussion may be useful.
The way I figured-out what file is read and caused Go to look for the compile binary in the wrong place can be solved using:
$ strace go tool -n compile 2>&1 |grep openat
openat(AT_FDCWD, "/home/nwaizer/.config/go/env", O_RDONLY|O_CLOEXEC) = 3
In that file, the IDE Goland, add a path to some project, causing the havoc.