go build gives "import <package>.a: not a package file" error

[radiat...@gmail.com]

Hi there,

I recently added a new package (lsfcommon) to my project and it's giving me some trouble when it comes to building.

go build -tags=lsf9 uniSched...

# uniSched/cmd/scrap

uniSched/cmd/scrap/scrap.go:4: import /work/scheduler/trunk/work/pkg/linux_amd64/gocommons/lsfcommon.a: not a package file

# uniSched/queuemonitor

uniSched/queuemonitor/queuemonitor.go:5: import /work/scheduler/trunk/work/pkg/linux_amd64/gocommons/lsfcommon.a: not a package file

# golsf/lsb

golsf/lsb/jobinfo.go:10: import /work/scheduler/trunk/work/pkg/linux_amd64/gocommons/lsfcommon.a: not a package file

The thing is, when I build with -a everything works fine, then immediately starts to fail again when I take the -a flag out.

Does anyone have any ideas what might be causing this? Leaving the -a flag in isn't really an acceptable workaround in our environment.

Cheers.

[Dave Cheney]

TL;DR, the command you want is go install, not go build

http://dave.cheney.net/2014/06/04/what-does-go-build-build

[mark mellar]

Thanks for your reply Dave. Unfortunately go install is giving me the same issues...

> go install -tags=lsf9 uniSched...

[Dave Cheney]

Just rm -rf $GOPATH/pkg and you should be fine.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/VGa3vprcNiE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mark mellar]

I haven't had much luck with that either...

> rm -rf /work/scheduler/trunk/work/pkg

> go install -tags=lsf9 uniSched...

# uniSched/cmd/scrap

uniSched/cmd/scrap/scrap.go:4: import /work/scheduler/trunk/work/pkg/linux_amd64/gocommons/lsfcommon.a: not a package file

# uniSched/queuemonitor

uniSched/queuemonitor/queuemonitor.go:5: import /work/scheduler/trunk/work/pkg/linux_amd64/gocommons/lsfcommon.a: not a package file

# golsf/lsb

golsf/lsb/jobinfo.go:10: import /work/scheduler/trunk/work/pkg/linux_amd64/gocommons/lsfcommon.a: not a package file

Thanks,

Mark.

[Dave Cheney]

Hmm, something is very odd with your setup.

First, have you set GOPATH to /work/scheduler/trunk/work/ ?

Second, are there only normal files under that path, the go tool does
not work with symlinks.

Third, do you have the correct ownership over that path ?

Fourth, please try % go install -tags=lsf9 uniSched/... <<< note the
forward slash between the d and the ...

Dave

[mark mellar]

/work/scheduler/trunk/work is the first thing on my gopath. We aren't doing anything fancy with symlinks. I own everything under that path, and adding the slash to the end of the package doesn't change anything.

I agree that there's something odd going on here :s. I've no idea what to investigate next.

Thanks,

Mark.

[James Bardin]

A couple things to try:

- Try re-installing the gocommons package by itself.

- Is the uniSched source absolute path actually "/work/scheduler/trunk/work/uniSched"?

- You said that is /work/scheduler/trunk/work is the *first* thing in your GOPATH. Is you have multiple GOPATH entries, try collapsing them down into a single new GOPATH. You could have some hidden link issues in there, nested paths, or possibly there's a bug with multiple GOPATHs (most people use a single GOPATH entry).

What's the output of `go env`?

[mark mellar]

Installing gocommons/lsfcommon on its own works fine. But even after doing this installing uniSched... gives the same errors.

The path to the source is actually /work/scheduler/trunk/work/src/uniSched, gocommons lives in the same directory.

I reduced my GOPATH to just /work/scheduler/trunk/work. Still no joy...

go env says...

e106647-lin:marmel01 > go env

GOROOT="<anonymised path to centralised tools repo>/golang/1.2/linux64"

GOBIN=""

GOARCH="amd64"

GOCHAR="6"

GOOS="linux"

GOEXE=""

GOHOSTARCH="amd64"

GOHOSTOS="linux"

GOTOOLDIR="<anonymised path to centralised tools reop>/golang/1.2/linux64/pkg/tool/linux_amd64"

GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread"

CGO_ENABLED="1"

Thanks,

Mark

[Jan Mercl]

On Thu, Aug 21, 2014 at 5:11 PM, mark mellar <radiat...@gmail.com> wrote:
> Installing gocommons/lsfcommon on its own works fine. But even after doing
> this installing uniSched... gives the same errors.
>
> The path to the source is actually /work/scheduler/trunk/work/src/uniSched,
> gocommons lives in the same directory.
>
> I reduced my GOPATH to just /work/scheduler/trunk/work. Still no joy...
>
> go env says...
>
> e106647-lin:marmel01 > go env
> GOROOT="<anonymised path to centralised tools repo>/golang/1.2/linux64"
> GOBIN=""
> GOARCH="amd64"
> GOCHAR="6"
> GOOS="linux"
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOTOOLDIR="<anonymised path to centralised tools
> reop>/golang/1.2/linux64/pkg/tool/linux_amd64"
> GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread"
> CGO_ENABLED="1"

The go env tool output mentions no GOPATH, which is not okay.

-j

[mark mellar]

I don't know what I'm doing wrong, I have the environment variable set...

 > echo $GOPATH

/work/scheduler/trunk/work

 > go env

GOROOT="<redacted>/golang/1.2/linux64"

GOBIN=""

GOARCH="amd64"

GOCHAR="6"

GOOS="linux"

GOEXE=""

GOHOSTARCH="amd64"

GOHOSTOS="linux"

GOTOOLDIR="<redacted>/golang/1.2/linux64/pkg/tool/linux_amd64"

GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread"

CGO_ENABLED="1"

[Jan Mercl]

Set is not enough, it must be exported. Try

$ export GOPATH=whatever

and run go env again.

(phone)

-j

[mark mellar]

I'm using tcsh which uses setenv to export environment variables.

> setenv GOPATH /work/scheduler/trunk/work

> echo $GOPATH

/work/scheduler/trunk/work

> go env

GOROOT="<redacted>/golang/1.3/linux64"

GOBIN=""

GOARCH="amd64"

GOCHAR="6"

GOOS="linux"

GOEXE=""

GOHOSTARCH="amd64"

GOHOSTOS="linux"

GOTOOLDIR="<redacted>/golang/1.3/linux64/pkg/tool/linux_amd64"

GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread"

CGO_ENABLED="1"

If I do `go list` it finds my packages fine...

> go list gocommons...

gocommons/abs

gocommons/amqp

gocommons/amqp/amqp_test

gocommons/amqp_sender

gocommons/defaults

gocommons/dispatcher

gocommons/dispatcher/buildserver

gocommons/dispatcher/local

gocommons/dispatcher/lsf

gocommons/dispatcher/spec

gocommons/logging

gocommons/logging/logserver_example

gocommons/lsfcommon

gocommons/util

gocommons/weedfs

Thanks,

Mark.

[Lars Seipel]

On Thu, Aug 21, 2014 at 11:09:14AM -0700, mark mellar wrote:
> GOTOOLDIR="<redacted>/golang/1.3/linux64/pkg/tool/linux_amd64"

Your last mails showed a path with version 1.2, now it's 1.3. Did you
just update to Go 1.3 or is there something weird going on? You might
want to double-check that you're not mixing tools from Go 1.2 and 1.3.

[mark mellar]

We have both installed, I just tried with 1.3 to see if it helped, unfortunately it's giving me the same set of errors.

Thanks,

Mark.

[Dave Cheney]

I think your problem may lie with the way your administrator has installed two versions of Go. Here are some suggestions

1. Do not under any circumstance set GOROOT

2. Build Go 1.2 / 1.3 in the final destination, the redacted path you mentioned above

2a. If this is not possible, you can try env GOROOT_FINAL=your redacted path ./all.bash, then moving the contents from your local build directory to GOROOT_FINAL taking care to not change any of the timestamps.

3. Don't set GOROOT, even for step 2a. 

This will ensure that the `go` binary you call will know exactly the path to the Go installation that matches it. Mixing bin/go and different runtime libraries will cause disastrous results, 

[ajinkya...@gmail.com]

This solution worked for me. Kind of late to the party though. :)