golang syntax error near unexpected token `newline' build error.md

tldr: go build only produces an executable for main packages. Check the package name of your main file is main.

I am an idiot. Its only through mistakes that you learn tho. I have recently been running into issues with my new golang projects. ONLY the new ones. Whenever I try to make a new project, it would always have issues. The biggest issue is the fact that "go build" would not produce an executable without "-o main.exe" as arguments. When an executable was produced, if I ran it I got

$ ./main.exe
./main.exe: line 1: syntax error near unexpected token \`newline\'
./main.exe: line 1: \`!<arch>\'

I thought that this was something wrong with my install. Possibly my environmental varaibles. The fact that it was only new projects should have directed me more to how the project was set up. Digging through said vairables proved not to help. Eventually I poked arround the go irc, (far and away the best place to go for help I'd actually go to the golang discord nowadays, but thats personal preference), and finally someone (Thank you neebs) was able to catch what I was doing wrong.

It had been so long since I last created a project, and I had only ever created one mod project from scratch, that I was confusing the errors that I got, and I kept trying to compile the following to an executable.

package lab5
import "fmt"
func main(){
	fmt.Println("Hello World")
}

The issue at hand is the package name. go build only produces an executable for main packages. IE "package main" with a func main().

package main
import "fmt"
func main(){
	fmt.Println("Hello World")
}

Not a mistake I will make again I think.

Thank you!

Thank you!

Thank you!

Thank you !

Thank you!

Thanks! 👍

Thank you!

Thanks!

By new projects I assume you were using go modules right @deef0000dragon1?

Thanks!

THANK YOU! Really great insight! You are actually not an idiot - you are enough self assured and self confident - also demonstrated enough humility to admit that - even skilled professionals need to debug things all the time and solve problems as they arise. By researching and reaching out to go.irc forums - you indicated - you are not a faint heart and not a novice - instead a self driven problem solver! The best part is - you shared your wisdom - unselfishly - helping like myself - not having to search all those forums myself.

THANK YOU and I benefited from your wisdom and you saved my cycles - hence you are my hero!

thx

Been coding Go for almost two years now and this stumped me tonight. I was trying to build a binary for a native OpenWhisk action and forgot that I had previously deployed my code to Google Cloud Functions, so my main function was in a package that wasn't called "main". Thanks for being the top Google result lol.

Thanks for saving me the time! Would have taken me a while to figure it out on my own. 👍

My IDE changed the package name when i moved files and this error was driving me crazy, thank you so much

Thank you!

And? How to produces an executable for non-main package?

 go build -o db_helper_app ./db_helper/
 chmod +x db_helper_app
./db_helper_app
./db_helper_app: line 1: syntax error near unexpected token `newline'
./db_helper_app: line 1: `!<arch>'

What the fuck?

@naddika Assuming you arent dealing with go plugins, with go build, you dont. Go build is not designed to operate like that.

As I summarized in the tldr at the top, and the second to last line & code block, you rename the package you are attempting to use as your entry-point to main, and make sure it has a main function akin to this.

package main
import (
    //Packages
)

func main(){
	// Application Entry Point
}

@naddika As @deefdragon said, you don't.

I wanted to suggest the Go docs page Organizing a Go module which does a great job demonstrating how to arrange Go code. It talks about code you don't want to be the entry point of executables (non-main packages) and code you want to be used for making executables (like you were trying to do).

I found this part of the page in particular useful:

Multiple programs in the same repository will typically have separate directories:

project-root-directory/
  go.mod
  internal/
    ... shared internal packages
  prog1/
    main.go
  prog2/
    main.go

In each directory, the program’s Go files declare package main. A top-level internal directory can contain shared packages used by all commands in the repository.

thank you