I have a few files in the main package under one directory:
main.go
config.go
server.go
When I do: "go build" the program builds perfect and runs fine.
When I do: "go run main.go" it fails.
Output:
# command-line-arguments
./main.go:7: undefined: Config
./main.go:8: undefined: Server
The symbols that are undefined are structs and they are capitalised so should be exported.
My Go version: go1.1.2 linux/amd64
This should work
go run main.go config.go server.go
Go run takes a file or files and it complies those and only those files which explains the missing symbols in the original post.
You could execute it as:
go run .
so you don't have to include all files manually.
Good practise would be to create a package for it and run
go run ./app
Ex. Folder Structure
├──app/
| ├──main.go
| ├──config.go
| ├──server.go
├──bin/
| ├──foo.go
└──pkg/
└──bar.go
Related
I build a simple "Hello, World" wasm app like:
GOARCH=wasm GOOS=js go build -o lib.wasm main.go
All is well. But then I want to test my code in my local (Linux) environment. So I change it to a pretty standard:
package main
import "fmt"
func main () {
fmt.Println("test")
}
And do a simple:
go run .
but now I get:
package xxx: build constraints exclude all Go files in xxx
I understand that if I specify a wasm build, I can't expect to run it locally. But I'm not trying to do a wasm build anymore. There are no build constraints in my .go source file, and my go.mod file just has the package and go version.
If I copy these file to a new directory and only do the go run . without the wasm build - all is good.
And if I do:
go build filename.go
it works properly.
It's like something "remembers" that this directory was supposed to be built with wasm - but I cant find what/where.
Is there a cache or something elsewhere that's remembering some build settings that I need to clear? I've tried go clean and go clean -cache - no luck!
The answer seems to be that if a filename ends in wasm.go - go will assume this is indeed a wasm file.
This means that a normal build or run will fail (if you don't specify proper OS and arch) - though a run with an explicit filename (even if it ends in wasm.go will work correctly.
???
I am facing an weird issue where after vendorising my dependencies with go modules, go build command is overriding the main.go file with random data.
Start of the file looks like this:
����
H
H__PAGEZEROx__TEXTpxpx__text__TEXT��7�__rodata__TEXT��7Y��7__symbol_stub1__TEXT�V��V�__typelink__TEXT�V�(�V__itablink__TEXTP#V�
P#V__gosymtab__TEXT�JV�JV__gopclntab__TEXTKV
"KV�__DATApx�|px c
__nl_symbol_ptr__DATApx�pxs__noptrdata__DATA�sx���sx__data__DATA�&{���&{__bss__DATA �{��__noptrbss__DATA�}�2__DWARF�}�{�� __zdebug_abbrev__DWARF�}�{__zdebug_line__DWARF�}'W�{__zdebug_frame__DWARF;H���;8�__zdebug_pubname__DWARF�څ�K�ʃ__zdebug_pubtype__DWARF�&����__debug_gdb_scri__DWARF��6�ӄ__zdebug_info__DWARF���
�ӄ__zdebug_loc__DWARF䉑��y�__zdebug_ranges__DWARFU��ZE�H__LINKEDIT�}L���L��*�����,�r��� Pu,u,x,xo�� /usr/lib/dyld 8/usr/lib/libSystem.B.dylib h/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation `/System/Library/Frameworks/Security.framework/Versions/A/Security$
� Go build ID: "OLftMbjtv5aWMkI_0qrD/LhWRtD0wcaKFWRYSDOa9/7dFWcNOQ4BpWWqZQW07D/pkR9ABiz-SHIBaJIZ1ur"
����������UH��AWAVATSH���=|I��
Go version: go version go1.12.5 darwin/amd64
Enabled Go moduled with export GO111MODULE=on
Folder structure:
go.mod go.sum log.go main.go vendor
FYI: only main.go is being overwritten, not log.go.
Go module initialised with go mod init
App vendorised with go mod vendor
Not sure if I am doing something wrong. Any help is appreciated.
The module name should not be main.go as it is a file inside a package. Please use your project name for module name in go mod init.
For example, if your project root is hello, name your package hello, not main.go.
Also if you want to use the module over and over again, please consider using your repository name as the module name.
Go handles packages not individual files. Go modules are used to organize packages. Know more in official documentation
I have main.go file
package main
func main() {
func2()
}
func2 is defined in file2.go:
package main
func func2(){
...
}
Everything is OK when I compile and run it from a command line:
go run main.go file2.go
But when I run it from Goland by pressing RUN it gives me an error:
# command-line-arguments
./main.go:95: undefined: func2
How should I overcome it?
Go to Run | Edit Configurations and change the run configuration Type to point from File to a Package, then the package name must be fully qualified (for example github.com/user/package).
Edit:
You can also right-click on the folder and then select Run | go test <folder name>. This will create a run configuration of the type Directory.
Note: there are differences between the Directory and Package type configurations.
I have to files main.go and main2.go . In main.go I have the main() function defined along with a call somefunc() which is in main2.go. The issue is that when I run go run main.go it says that somefunc() is undefined. Basically it doesn't scan the other main functions from package. However if I declare this somefunc() in main.go it works but when I run go test it says the function is redeclared.
Question: Is there any way that I can tell to go run to behave like go test and compile/run all the files from the package(in this case both main.go and main1.go) not just main.go?
You must include all the files as argument of the go run.
go run main1.go main.go
or
go *.go
Unless there are test files in the same folder.
The directory structure is :
src
src/pkg
src/pkg/t1.go
src/pkg/t1_test.go
t1.go
package pkg
import (
"fmt"
)
func SayHI(){
fmt.Println("this is t1")
}
t1_test.go
package pkg
import (
"testing"
)
func TestXYZ(t *testing.T) {
SayHI()
}
Invoke go test from command line at dir src/pkg
go test t1_test.go
error:
./t1_test.go:8: undefined: SayHI
FAIL command-line-arguments [build failed]
but the function is there
thanks for any hints
It is working as intended.
jnml#fsc-r630:~/src/pkg$ go help test
usage: go test [-c] [-i] [build flags] [packages] [flags for test binary]
'Go test' automates testing the packages named by the import paths.
It prints a summary of the test results in the format:
ok archive/tar 0.011s
FAIL archive/zip 0.022s
ok compress/gzip 0.033s
...
followed by detailed output for each failed package.
'Go test' recompiles each package along with any files with names matching
the file pattern "*_test.go". These additional files can contain test functions,
benchmark functions, and example functions. See 'go help testfunc' for more.
By default, go test needs no arguments. It compiles and tests the package
with source in the current directory, including tests, and runs the tests.
The package is built in a temporary directory so it does not interfere with the
non-test installation.
In addition to the build flags, the flags handled by 'go test' itself are:
-c Compile the test binary to pkg.test but do not run it.
-i
Install packages that are dependencies of the test.
Do not run the test.
The test binary also accepts flags that control execution of the test; these
flags are also accessible by 'go test'. See 'go help testflag' for details.
For more about build flags, see 'go help build'.
For more about specifying packages, see 'go help packages'.
See also: go build, go vet.
jnml#fsc-r630:~/src/pkg$
In other words:
go test is okay.
go test pkg (assuming $GOPATH is ~ and the package is in ~/src/pkg) is okay.
go test whatever_test.go is not okay as that is not supported as documented above.
To select which tests to run use the -run <regular_expression> flag (where the <regular_expression> is interpreted as having wildcards on either end, like .*<regular_expression>.*). For example
$ go test -run Say # from within the package's directory
or
$ go test -run Say my/package/import/path # from anywhere
This is somewhat strange in Golang. To be honest it took me some time to figure a way out.
A simple work-around is to include them in the command, eg:
go test src/pkg/t1.go src/pkg/t1_test.go
IMHO, The best way is to keep it clean. So avoid having more than 1 file as dependency per test file. If you are using +1 file as dependency, consider creating a black-box test with a _test package and do not make use of any lowerCase internal vars.
This will avoid you having to deal with complicated dependencies on your day to day testing.
Run
go test ./...
This will find all the tests in all test files. To run individual tests, specify the dependencies like here.
I came across this Stackoverflow question after encountering the exact same issue myself: specifically, attempting to run go test and then seeing a build failure indicating that the function in question isn't defined. I see that this question is somewhat old now (asked 8 years ago) but in my case the issue was that I was attempting to write code in Go 1.16 that seems to now assume the presence/use of modules. See this page for a starting reference on modules and easy follow-along example.
All I had to do in my case was run go mod init [module name] and after that I could run go test without any issues.
Hopefully this is of some value to users coming to this page after using a more modern (1.16+) version of Go.