43
votes

I've been having a hard time trying to execute a simple golang program in a virtual machine powered by vagrant. These are the relevant fields of my go env:

GOARCH="amd64"
GOPATH="/usr/local/src/go"
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"

This is the program I'm trying to execute ( located in /usr/local/src/go/program ):

package program

import (
    "fmt"
)

func main() {
    fmt.Print("Aloha")
}

This, the output that I get:

main.go:4:5:
/usr/local/go/src/fmt/doc.go:1:1: expected 'package', found 'EOF'
package runtime:
/usr/local/go/src/runtime/alg.go:1:1: expected 'package', found 'EOF'

Take into account that this is a completely fake program. The weird thing is that it totally works in a different environment. What am I missing here?

Thanks a lot!

11
Did you saved your program.go source file before calling go run? And wouldn't it work better with package main?VonC
Thanks for the reply! Yes, package main would be more appropriate. That's how it used to be and was failing with the exact same error. Sure, the file was saved ;)ThisIsErico
Is there some kind of eol error (windows end of line instead of unix?)VonC
Not really either :(ThisIsErico
Interesting... Of course I'm getting an EOF... The files are indeed empty. The go get execution seems to be failing at some point.ThisIsErico

11 Answers

83
votes

Using VS Code for GO, and faced the same issue. Saving the file 'Ctrl+S' on Windows fixed the issue.

Reference : Answered by Nico

27
votes

This usually happens when you have a file e.g. foo_test.go empty or without package declaration.

17
votes

Just save the file first and than run the cammand.it is working.

go run main.go

12
votes

The problem wasn't neither with GOROOT nor GOPATH. The go installation failed at some point, leaving the whole thing unstable ( files created but completely empty ). When provisioning the virtual machine again, the go module checked whether the files existed. As they did, it took by granted that the installation had already take place.

A clean up and fresh installation from scratch solved the problem.

7
votes

With gopls (v0.4.0 at the time of writing, so pretty unstable!) and vscode doing cmd+shift+P > Go: Restart language server worked for me.

4
votes

I have faced exactly same issue today while running golang in vscode.

enter image description here

Error

enter image description here

This usually happen when you don't save code and run code directly thinking IDE like Intellij does autosave for us, but in vscode you can enable autosave to avoid this kind of error and save some time.

Go to File -> Auto save

3
votes

For me, this also happened using Atom + Go Plus + Terminal Plus. The problem was that leading bracket was not on the "correct" line.

NOTE: Go Plus warns about syntax upon save, but I had imported this file after creating it locally with VIM, so I was never presented with the lint errors...

Error:

package main
import "fmt"
func main() 
{
    fmt.Println("hello world")
}

Correct:

package main
import "fmt"
func main() {
    fmt.Println("hello world")
}
3
votes

A separate Go file in the same package,didn't have the "package main" declaration and because of this the console was giving errors on running the Main GO file.

On providing the package main declaration to the other Go file ,the error stopped showing.

1
votes

In my case i was solve the problem by Using "VS Code" instead of default "text editor"

The problem was some extra characters present in the file. Once we remove extra characters it will work.

I wish it will solve to you also.

0
votes

As said by already suggested by Nico, When you create a new project and new main.go file this error will appear when the file is not saved. Save the file (ctrl + s) and this error will disappear in both mac & windows. I faced the same issue and just got it resolved by doing ctrl+S on the main.go file.

-2
votes

As a new go user I came upon this answer looking for someone to tell me that I need to start my scripts with package main although my error was a little different,

... expected 'package', found 'import'

It's real obvious now, but hey, that's how it goes.