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 from the 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?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
