The symptom is that a single command
% docker run <args> <docker_image> go install <args>
would fail at importing Go packages, but running them separately, i.e.
% docker run -it <docker_image> bash
(with the source files copied over to same location)
% go install <args>
would work just fine.
Details below:
The build command came from a Makefile:
@$(DRUN) \ -v $(abspath build/docker/bin):/opt/gopath/bin \ -v $(abspath build/docker/$(TARGET)/pkg):/opt/gopath/pkg \ $(BASE_DOCKER_NS)/fabric-baseimage:latest \ go install -x -ldflags "$(DOCKER_GO_LDFLAGS)" peer
- For the failing case, fail is located at a ‘gccgo’ command:
% /usr/bin/gccgo -I $WORK -I /opt/gopath/pkg/gccgo_linux_sparc64 -c -g -fgo-pkgpath=github.com/hyperledger/fabric/common/flogging -fgo-relative-import-path=_/opt/gopath/src/github.com/hyperledger/fabric/common/flogging -o $WORK/github.com/hyperledger/fabric/common/flogging/_obj/_go_.o ./logging.go github.com/hyperledger/fabric/common/flogging common/flogging/logging.go:26:26: error: import file 'github.com/op/go-logging' not found "github.com/op/go-logging" ^
Tracing the sys calls, the program is able to locate the ‘go-logging’ package, but failed to see any’.gox’ ‘.so’ ‘.a’ ‘.o’ file.
% strace -f -o aa /usr/bin/gccgo <args> <args> logging.go (args same with above) open("/opt/gopath/src/github.com/op/go-logging", O_RDONLY) = 10 open("/opt/gopath/src/github.com/op/go-logging.gox", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/gopath/src/github.com/op/libgo-logging.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/gopath/src/github.com/op/libgo-logging.a", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/gopath/src/github.com/op/go-logging.o", O_RDONLY) = -1 ENOENT (No such file or directory)
For the working case, where the same command:
% /usr/bin/gccgo -I $WORK -I /opt/gopath/pkg/gccgo_linux_sparc64 -c -g -fgo-pkgpath=github.com/hyperledger/fabric/common/flogging -fgo-relative-import-path=_/opt/gopath/src/github.com/hyperledger/fabric/common/flogging -o $WORK/github.com/hyperledger/fabric/common/flogging/_obj/_go_.o ./logging.go
was separately invoked inside the container itself, while tracing the syscalls:
open("/opt/gopath/pkg/gccgo_linux_sparc64/github.com/op/go-logging", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/gopath/pkg/gccgo_linux_sparc64/github.com/op/go-logging.gox", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/gopath/pkg/gccgo_linux_sparc64/github.com/op/libgo-logging.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/opt/gopath/pkg/gccgo_linux_sparc64/github.com/op/libgo-logging.a", O_RDONLY) = 10
the ‘.a’ file is found.
I understand that while compiling program with gccgo
When you import the package FILE with gccgo, it will look for the import data in the following files, and use the first one that it finds.
FILE.gox FILE.o libFILE.so libFILE.a
The gccgo compiler will look in the current directory for import files
So for some reason, the’.a’ file was not generated for the failing case, but was, when ‘go install’ was invoked inside the container.
Any insights?