./main.go:10:2: undefined: X

The exact error string

$ go build .
./main.go:10:2: undefined: greetUser
./handler.go:22:9: undefined: strings.Trimm

Go's build failures always carry a file:line:column prefix and stop the entire build — there is no partial binary, and no way to run code that references an unresolved name, even if that name is never actually called at runtime. This is a stricter guarantee than most dynamic languages offer: a Python or JavaScript program can run for hours before hitting an undefined name on a rarely-exercised code path, but Go's compiler resolves every identifier in every reachable file before producing anything at all.

How to read the message

The format is always undefined: <name> or undefined: <package>.<name>. The second form is the easier case: the package half already resolved (the import exists and is used), so the search space narrows to "does this exact member exist in that package" — almost always a typo of a real standard-library or third-party function name. The first form, a bare identifier, requires checking the four causes below in order, since the compiler gives no further hint about which one applies.

Cause 1: a typo in the identifier name

func greetUser(name string) string {
    return "Hello, " + name
}

func main() {
    fmt.Println(greetUsr("Ada"))   // ❌ undefined: greetUsr (typo)
}

// ✅ fix: match the exact spelling
fmt.Println(greetUser("Ada"))

The simplest and most common cause. Go's identifier resolution is exact-match only — there is no fuzzy matching or "did you mean" at the compiler level (though gopls-powered editors surface a suggestion as you type). A single dropped or transposed letter, especially in a long camelCase name, produces this error with no other symptom.

Cause 2: the package isn't imported (or isn't referenced with its prefix)

// ❌ no import for "strings" — every strings.* call is undefined
func clean(s string) string {
    return strings.TrimSpace(s)   // undefined: strings
}

// ✅ import the package the identifier lives in
import "strings"

func clean(s string) string {
    return strings.TrimSpace(s)
}

Go requires every package you reference to appear in the file's import block — there's no implicit global namespace the way some languages provide for their standard library. Copy-pasting a code snippet from documentation or another file without also copying its imports is the most common trigger; goimports (bundled with most Go tooling) can auto-add the missing import once you save, which is why editors configured with it rarely show this specific variant.

Cause 3: the identifier is unexported and you're calling it from another package

// file: internal/user/user.go, package user
func validateEmail(e string) bool { ... }   // lowercase = unexported

// file: main.go, package main
import "myapp/internal/user"

func main() {
    user.validateEmail("a@b.com")   // ❌ undefined: user.validateEmail
}

// ✅ export it by capitalizing the first letter, in its own package
func ValidateEmail(e string) bool { ... }
// then call it as user.ValidateEmail(...) from main.go

Go has no export or public keyword — visibility is determined entirely by the case of the first letter, a design choice that makes the export boundary visible directly in the name at every call site, with no need to check a separate declaration. An identifier starting with a lowercase letter is scoped to its own package only; referencing it with a package prefix from anywhere else fails to resolve, and the compiler reports it identically to a genuinely nonexistent name, since from the importing package's perspective, it effectively doesn't exist.

Cause 4: the defining file is excluded by a build tag for this build

// file: platform_linux.go
//go:build linux

package main
func platformInit() { ... }

// file: main.go — building on macOS or Windows:
func main() {
    platformInit()   // ❌ undefined: platformInit (file excluded on this OS)
}

// ✅ provide a version for every platform you build on, or a
//    fallback with a broader/negated constraint:
//go:build !linux
func platformInit() { /* no-op or generic fallback */ }

A //go:build constraint (or the older _linux.go / _windows.go / _test.go filename-suffix convention) tells the compiler to skip that entire file unless the stated condition matches the current GOOS/GOARCH or build mode. The function is textually present in your repository, your editor can even navigate to its definition, but the compiler for this specific build never parses that file at all — making this the least intuitive of the four causes, since nothing about the source code itself looks wrong.

Common variants at a glance

Why this happens: Go resolves names at compile time, exhaustively

Unlike a scripting language that resolves a name only when the line actually executes, Go's compiler performs identifier resolution across every file it decides to compile for the current build, before generating any code. This is a deliberate trade-off: it catches typos and missing imports in dead code paths that might never run in a dynamic language, at the cost of requiring every referenced name to genuinely exist and be visible before the program can run at all. The practical implication is that "undefined" is never a runtime surprise in Go the way a NameError can be in Python — it's always caught at the earliest possible point, which is also why the four causes above are exhaustive: there's no fifth category of "the name exists but something else went wrong," because name resolution is a single, total, compile-time pass.

Debugging checklist

• ✓ Re-read the exact spelling and case of the identifier named in the error
• ✓ Confirm the package it lives in is in your import block
• ✓ If it's a cross-package call, confirm the identifier starts with an uppercase letter (exported)
• ✓ Check the defining file for a //go:build line or an OS/test filename suffix
• ✓ Run go build ./... (not just your editor's live check) to confirm the fix across the whole module