Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: dots in import statement causes error in finding packages under $GOPATH #20391

Closed
bertverhees opened this issue May 17, 2017 · 15 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@bertverhees
Copy link

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.8.1 linux/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/verhees/development/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build251409227=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?

I did: go get github.com/antlr/antlr4/runtime/Go/antlr

I run the antlr grammar and had the result go-files in the directory parser which is a subdirectory from the project directory (which is again a subdirectory of the $GOPATH/src

I used the library in import like this:

import (
"github.com/antlr/antlr4/runtime/Go/antlr"
"./parser"
"os"
"fmt"
)

What did you expect to see?

I expected to see the program (very small program ) run

What did you see instead?

I got an error:
/usr/local/go/pkg/tool/linux_amd64/link: cannot open file /usr/local/go/pkg/linux_amd64/github.com/antlr/antlr4/runtime/Go/antlr.a: open /usr/local/go/pkg/linux_amd64/github.com/antlr/antlr4/runtime/Go/antlr.a: no such file or directory

It was clear that it did not look in the $GOPATH/src diectory for the module.

I found somewhere on the internet something about dots in an import statement, and I changed my import like this:
import (
"github.com/antlr/antlr4/runtime/Go/antlr"
"antlr_experiments/JSON_experiment/parser"
"os"
"fmt"
)

And now everything runs fine.

Thanks for reading, I hope this is useful for you.

@ianlancetaylor ianlancetaylor changed the title Dots in import statement causes error in finding packages under $GOPATH cmd/go: dots in import statement causes error in finding packages under $GOPATH May 17, 2017
@ianlancetaylor
Copy link
Contributor

We need more details. Please show us the exact file layout of your GOPATH directory for the case that fails. Thanks.

@bertverhees
Copy link
Author

bertverhees commented May 17, 2017

~/development/go > tree -L 2

.
├── bin
├── pkg
│   └── linux_amd64
└── src
    ├── antlr_experiments
    ├── github.com
    ├── iso_oid
    ├── learning-go
    ├── openehr
    └── update.sh

9 directories, 1 file

@ianlancetaylor
Copy link
Contributor

Thanks, but we really need to see all the files under src.

@bertverhees
Copy link
Author

I wouldn't bother to answer at all if I were you. What you ask is ridicolous. You should have warned me before I spent time reporting a problem.

@bradfitz
Copy link
Contributor

Do you want us to close this bug, then?

@ianlancetaylor
Copy link
Contributor

@bertverhees Why is it ridiculous? Thanks for reporting the problem, but right now we simply don't have enough information to identify and solve it. The error you are reporting is an inability to open antlr.a; I don't understand how that corresponds to a change in how you refer to parser. I could try to guess at how to recreate this, but you already have exactly the information we need. Why not tell us?

@bertverhees
Copy link
Author

bertverhees commented May 18, 2017

You asked to see ALL files under src, which is my complete work I wrote in Go. Which I find ridiculous to ask. Now you ask for one file to recreate the problem. That is reasonable. I will do this today.

@bertverhees
Copy link
Author

bertverhees commented May 18, 2017

#Downloading and installing the antlr package

verhees 08:44:27 ~/go > go get github.com/antlr/antlr4/runtime/Go/antlr

verhees 08:46:37 ~/go > tree -L 4

.
├── bin
├── pkg
│   └── linux_amd64
│       └── github.com
│           └── antlr
└── src
    └── github.com
        └── antlr
            └── antlr4

9 directories, 0 files

verhees 08:55:51 ~/go/src > tree -L 4

.
├── antlr_experiments
│   └── code
│       └── hello
│           ├── parser
│           └── Test.go
└── github.com
    └── antlr
        └── antlr4
            ├── antlr4-maven-plugin
            ├── appveyor.yml
            ├── build
            ├── CHANGES.txt
            ├── CONTRIBUTING.md
            ├── contributors.txt
            ├── doc
            ├── LICENSE.txt
            ├── pom.xml
            ├── README.md
            ├── runtime
            ├── runtime-testsuite
            ├── scripts
            ├── tool
            └── tool-testsuite

#creating the antlr Hello world project, as you can see, I have the generated files all in the directory parser.
If you check the files, you see they are of packager parser.

And I myself have written one file in package main, in the root directory of this project.

verhees 08:57:50 ~/go/src/antlr_experiments > tree

.
└── code
    └── hello
        ├── parser
        │   ├── hello_base_listener.go
        │   ├── Hello.g4
        │   ├── hello_lexer.go
        │   ├── HelloLexer.tokens
        │   ├── hello_listener.go
        │   ├── hello_parser.go
        │   └── Hello.tokens
        └── Test.go

3 directories, 8 files

When I have the import-statement in the Test.go like this
(commented out "./parser")

import (
        "github.com/antlr/antlr4/runtime/Go/antlr"
        "antlr_experiments/code/hello/parser"
        //"./parser"
        "os"
        "fmt"
        "bufio"
)

verhees 09:01:30 ~/go/src/antlr_experiments/code/hello > go run Test.go
Enter text: hello golang
hellogolang

(this is what the program should do)

Now I change it to this

import (
        "github.com/antlr/antlr4/runtime/Go/antlr"
        //"antlr_experiments/code/hello/parser"
        "./parser"
        "os"
        "fmt"
        "bufio"
)

This happens:
verhees 09:03:07 ~/go/src/antlr_experiments/code/hello > go run Test.go
command-line-arguments
/usr/local/go/pkg/tool/linux_amd64/link: cannot open file /usr/local/go/pkg/linux_amd64/github.com/antlr/antlr4/runtime/Go/antlr.a: open /usr/local/go/pkg/linux_amd64/github.com/antlr/antlr4/runtime/Go/antlr.a: no such file or directory

I have uploaded all files of this project

hello.zip

(again, to check my configuration)
verhees 09:10:17 ~/go/src/antlr_experiments/code/hello > go version
go version go1.8.1 linux/amd64

verhees 09:10:23 ~/go/src/antlr_experiments/code/hello > go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/verhees/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build560428636=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

@bertverhees
Copy link
Author

I come to this question because of this:
https://golang.org/cmd/go/#hdr-Relative_import_paths

It has following text:
Second, if you are compiling a Go program not in a work space, you can use a relative path in an import statement in that program to refer to nearby code also not in a work space. This makes it easy to experiment with small multipackage programs outside of the usual work spaces

I think this is an error, to check that I made up this call.

@ianlancetaylor
Copy link
Contributor

Thanks for the test case. I can recreate the problem now.

This is a complicated scenario. The text you quote explains that relative imports are supported when you aren't in a workspace--that is, when you aren't working under GOPATH. In this case, though, you are working under GOPATH. The go tool doesn't generally support relative imports for code that is under GOPATH. You will see a sensible error if you simply type go run. But since you are typing go run Test.go, the go tool is treating this file as though it weren't in a workspace. It builds the ./parser package locally, but seems to get confused about the reference to the github.com/antlr/antlr4/runtime/Go/antrl package. It tries to find it locally and fails, and it tries to find it in GOROOT and fails, but it doesn't look in GOPATH.

So you are clearly doing something that the go tool isn't designed for. Either work in GOPATH and use GOPATH-relative addresses, or work outside GOPATH and use directory-relative addresses. Don't try to mix and match.

But that said, what you are trying to do should either work or should give a sensible error message, and right now it does neither. So there is a bug here, although at the moment I'm not sure what the right fix is.

@ianlancetaylor ianlancetaylor added this to the Go1.10 milestone May 18, 2017
@bertverhees
Copy link
Author

Thanks, that explains. Hint for the errormessage: It should explain where it searches for the github path, also indicate that I tried to solve it in the relative path. It costed me nearly a day to find out, but worse, the frustration and uncertainty. Specially because I am combining Go with Antlr which is quite new, and everything can go wrong.

Thanks for your explanation
Best regards
Bert

@fraenkel
Copy link
Contributor

The cited section does make it clear, see the last line.
To avoid ambiguity, Go programs cannot use relative import paths within a work space.

@bertverhees
Copy link
Author

bertverhees commented May 24, 2017

thanks for the answer, the difference between go run and go run FileName.go in the context of relative/absolut paths was not clear to me, but afterwards, it is a reasonable difference

@rsc
Copy link
Contributor

rsc commented Dec 1, 2017

I will try to clean the error up during some work on cmd/go next cycle.

@rsc rsc modified the milestones: Go1.10, Go1.11 Dec 1, 2017
@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Go1.12 Jul 6, 2018
@ianlancetaylor ianlancetaylor added the NeedsFix The path to resolution is known, but the work has not been done. label Jul 6, 2018
@rsc
Copy link
Contributor

rsc commented Oct 25, 2018

I can't reproduce this today, and I think the module loader already has a better error. Closing.

Feel free to submit a new bug with a simpler repro case if you are still seeing the confusing error.

@rsc rsc closed this as completed Oct 25, 2018
@golang golang locked and limited conversation to collaborators Oct 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants