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.

Sign up for GitHub

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

Jump to bottom

cmd/go: build failures in git tip in TestGoPathShlibGccgo and TestTwoGopathShlibsGccgo #25324

Closed
siebenmann opened this issue May 10, 2018 · 2 comments
Closed

cmd/go: build failures in git tip in TestGoPathShlibGccgo and TestTwoGopathShlibsGccgo #25324

siebenmann opened this issue May 10, 2018 · 2 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone
Go1.11

Comments

@siebenmann
Copy link

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

go version devel +10529a01fd Wed May 9 22:10:32 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?

This issue isn't in 1.10.2; it appeared only in recent git tip versions.

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

GOARCH="amd64" and GOOS="linux".

What did you do?

Building Go from source with ./all.bash now fails with:

##### ../misc/cgo/testshared
--- FAIL: TestGoPathShlibGccgo (0.11s)
        shared_test.go:67: executing go install -installsuffix=5577006791947779410 -compiler=gccgo -linkshared exe failed exit status 1:
                package exe
                        imports runtime/cgo: cannot find package "runtime/cgo" in any of:
                        /data/code/go-lang/go/src/runtime/cgo (from $GOROOT)
                        /tmpfs/testshared267296232/src/runtime/cgo (from $GOPATH)
--- FAIL: TestTwoGopathShlibsGccgo (0.21s)
        shared_test.go:67: executing go install -installsuffix=5577006791947779410 -compiler=gccgo -linkshared exe2 failed exit status 1:
                package exe2
                        imports runtime/cgo: cannot find package "runtime/cgo" in any of:
                        /data/code/go-lang/go/src/runtime/cgo (from $GOROOT)
                        /tmpfs/testshared267296232/src/runtime/cgo (from $GOPATH)
FAIL
exit status 1
FAIL    _/data/code/go-lang/go/misc/cgo/testshared      11.861s
2018/05/09 22:39:32 Failed: exit status 1

According to a git bisect run, the commit that this starts happening at is d540da1. It's not clear to me why this is happening, because /data/code/go-lang/go/src/runtime/cgo exists and contains what you'd expect (/data/code/go-lang/go is the location of my git Go source tree).
@ianlancetaylor ianlancetaylor added NeedsFix The path to resolution is known, but the work has not been done. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 10, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone May 10, 2018
@gopherbot gopherbot removed the NeedsFix The path to resolution is known, but the work has not been done. label May 10, 2018
@ianlancetaylor ianlancetaylor added NeedsFix The path to resolution is known, but the work has not been done. release-blocker and removed NeedsFix The path to resolution is known, but the work has not been done. labels May 10, 2018
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/113716 mentions this issue: cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/114516 mentions this issue: cmd/go, cmd/vet: make vet work with gccgo

gopherbot pushed a commit to golang/gofrontend that referenced this issue May 30, 2018
@ianlancetaylor
cmd/go, cmd/vet: make vet work with gccgo
9731580 
Backport https://golang.org/cl/113715 and https://golang.org/cl/113716:

cmd/go: don't pass -compiler flag to vet

Without this running go vet -compiler=gccgo causes vet to fail.
The vet tool does need to know the compiler, but it is passed in
vetConfig.Compiler.

cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo

When using gccgo/GoLLVM, there is no package file for a standard
library package. Since it is impossible for the go tool to rebuild the
package, and since the package file exists only in the form of a .gox
file, this seems like the best choice. Unfortunately it was confusing
vet, which wanted to see a real file. This caused vet to report errors
about missing package files for standard library packages. The
gccgoimporter knows how to correctly handle this case. Fix this by

1) telling vet which packages are standard;
2) letting vet skip those packages;
3) letting the gccgoimporter handle this case.

As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
so don't try to depend on it (as it happens, this fixes golang/go#25324).

The result is that the cmd/go vet tests pass when using -compiler=gccgo.

Change-Id: I3d3ffbfc7196144c75430aa6a6a1013e472b121f
Reviewed-on: https://go-review.googlesource.com/114516
Reviewed-by: Than McIntosh <thanm@google.com>
hubot pushed a commit to gcc-mirror/gcc that referenced this issue May 30, 2018
cmd/go, cmd/vet: make vet work with gccgo
70d336e 
    
    Backport https://golang.org/cl/113715 and https://golang.org/cl/113716:
    
    cmd/go: don't pass -compiler flag to vet
    
    Without this running go vet -compiler=gccgo causes vet to fail.
    The vet tool does need to know the compiler, but it is passed in
    vetConfig.Compiler.
    
    cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo
    
    When using gccgo/GoLLVM, there is no package file for a standard
    library package. Since it is impossible for the go tool to rebuild the
    package, and since the package file exists only in the form of a .gox
    file, this seems like the best choice. Unfortunately it was confusing
    vet, which wanted to see a real file. This caused vet to report errors
    about missing package files for standard library packages. The
    gccgoimporter knows how to correctly handle this case. Fix this by
    
    1) telling vet which packages are standard;
    2) letting vet skip those packages;
    3) letting the gccgoimporter handle this case.
    
    As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
    so don't try to depend on it (as it happens, this fixes golang/go#25324).
    
    The result is that the cmd/go vet tests pass when using -compiler=gccgo.
    
    Reviewed-on: https://go-review.googlesource.com/114516


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@260913 138bc75d-0d04-0410-961f-82ee72b054a4
hubot pushed a commit to gcc-mirror/gcc that referenced this issue May 31, 2018
PR go/85429
50e2009 
Various backports from mainline:

    libgo: update to Go 1.10.2 release

    cmd/go: support more Solaris assembler syntaxes
   
    Patch by Rainer Orth.
   
    cmd/go: update to match recent changes to gc
   
    In https://golang.org/cl/111097 the gc version of cmd/go was updated
    to include some gofrontend-specific changes. The gofrontend code
    already has different versions of those changes; this CL makes the
    gofrontend match the upstream code.
 
    cmd/go, cmd/vet: make vet work with gccgo
   
    Backport https://golang.org/cl/113715 and https://golang.org/cl/113716:
   
    cmd/go: don't pass -compiler flag to vet
   
    Without this running go vet -compiler=gccgo causes vet to fail.
    The vet tool does need to know the compiler, but it is passed in
    vetConfig.Compiler.
   
    cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo
   
    When using gccgo/GoLLVM, there is no package file for a standard
    library package. Since it is impossible for the go tool to rebuild the
    package, and since the package file exists only in the form of a .gox
    file, this seems like the best choice. Unfortunately it was confusing
    vet, which wanted to see a real file. This caused vet to report errors
    about missing package files for standard library packages. The
    gccgoimporter knows how to correctly handle this case. Fix this by
   
    1) telling vet which packages are standard;
    2) letting vet skip those packages;
    3) letting the gccgoimporter handle this case.
   
    As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
    so don't try to depend on it (as it happens, this fixes golang/go#25324).
   
    The result is that the cmd/go vet tests pass when using -compiler=gccgo.

    crypto/x509: specify path to AIX certificate file

    go/build, cmd/go: update to match recent changes to gc
   
    Several recent changes to the gc version of cmd/go improve the
    gofrontend support. These changes are partially copies of existing
    gofrontend differences, and partially new code. This CL makes the
    gofrontend match the upstream code.
   
    The changes included here come from:
        https://golang.org/cl/111575
        https://golang.org/cl/111595
        https://golang.org/cl/111635
        https://golang.org/cl/111636
   
    For the record, the following recent gc changes are based on code
    already present in the gofrontend repo:
        https://golang.org/cl/110915
        https://golang.org/cl/111615
   
    For the record, a gc change, partially based on earlier gofrontend
    work, also with new gc code, was already copied to gofrontend repo in
    CL 111099:

    https://golang.org/cl/111097
    
    This moves the generated list of standard library packages from
    cmd/go/internal/load to go/build.

gotools/ChangeLog:

	Backport from mainline:
	2018-05-09  Ian Lance Taylor  <iant@golang.org>
	* Makefile.am (check-go-tool): Don't copy zstdpkglist.go.
	* Makefile.in: Rebuild.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-8-branch@261045 138bc75d-0d04-0410-961f-82ee72b054a4
@golang golang locked and limited conversation to collaborators May 24, 2019
kraj pushed a commit to kraj/gcc that referenced this issue Jan 11, 2020
@ianlancetaylor
re PR go/85429 (Several gotools tests FAIL with Solaris as)
8cebf43 
	PR go/85429

Various backports from mainline:

    libgo: update to Go 1.10.2 release

    cmd/go: support more Solaris assembler syntaxes
   
    Patch by Rainer Orth.
   
    cmd/go: update to match recent changes to gc
   
    In https://golang.org/cl/111097 the gc version of cmd/go was updated
    to include some gofrontend-specific changes. The gofrontend code
    already has different versions of those changes; this CL makes the
    gofrontend match the upstream code.
 
    cmd/go, cmd/vet: make vet work with gccgo
   
    Backport https://golang.org/cl/113715 and https://golang.org/cl/113716:
   
    cmd/go: don't pass -compiler flag to vet
   
    Without this running go vet -compiler=gccgo causes vet to fail.
    The vet tool does need to know the compiler, but it is passed in
    vetConfig.Compiler.
   
    cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo
   
    When using gccgo/GoLLVM, there is no package file for a standard
    library package. Since it is impossible for the go tool to rebuild the
    package, and since the package file exists only in the form of a .gox
    file, this seems like the best choice. Unfortunately it was confusing
    vet, which wanted to see a real file. This caused vet to report errors
    about missing package files for standard library packages. The
    gccgoimporter knows how to correctly handle this case. Fix this by
   
    1) telling vet which packages are standard;
    2) letting vet skip those packages;
    3) letting the gccgoimporter handle this case.
   
    As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
    so don't try to depend on it (as it happens, this fixes golang/go#25324).
   
    The result is that the cmd/go vet tests pass when using -compiler=gccgo.

    crypto/x509: specify path to AIX certificate file

    go/build, cmd/go: update to match recent changes to gc
   
    Several recent changes to the gc version of cmd/go improve the
    gofrontend support. These changes are partially copies of existing
    gofrontend differences, and partially new code. This CL makes the
    gofrontend match the upstream code.
   
    The changes included here come from:
        https://golang.org/cl/111575
        https://golang.org/cl/111595
        https://golang.org/cl/111635
        https://golang.org/cl/111636
   
    For the record, the following recent gc changes are based on code
    already present in the gofrontend repo:
        https://golang.org/cl/110915
        https://golang.org/cl/111615
   
    For the record, a gc change, partially based on earlier gofrontend
    work, also with new gc code, was already copied to gofrontend repo in
    CL 111099:

    https://golang.org/cl/111097
    
    This moves the generated list of standard library packages from
    cmd/go/internal/load to go/build.

gotools/ChangeLog:

	Backport from mainline:
	2018-05-09  Ian Lance Taylor  <iant@golang.org>
	* Makefile.am (check-go-tool): Don't copy zstdpkglist.go.
	* Makefile.in: Rebuild.

From-SVN: r261045
asiekierka pushed a commit to WonderfulToolchain/gcc-ia16 that referenced this issue May 16, 2022
cmd/go, cmd/vet: make vet work with gccgo
bb3976d 
    
    Backport https://golang.org/cl/113715 and https://golang.org/cl/113716:
    
    cmd/go: don't pass -compiler flag to vet
    
    Without this running go vet -compiler=gccgo causes vet to fail.
    The vet tool does need to know the compiler, but it is passed in
    vetConfig.Compiler.
    
    cmd/go, cmd/vet, go/internal/gccgoimport: make vet work with gccgo
    
    When using gccgo/GoLLVM, there is no package file for a standard
    library package. Since it is impossible for the go tool to rebuild the
    package, and since the package file exists only in the form of a .gox
    file, this seems like the best choice. Unfortunately it was confusing
    vet, which wanted to see a real file. This caused vet to report errors
    about missing package files for standard library packages. The
    gccgoimporter knows how to correctly handle this case. Fix this by
    
    1) telling vet which packages are standard;
    2) letting vet skip those packages;
    3) letting the gccgoimporter handle this case.
    
    As a separate required fix, gccgo/GoLLVM has no runtime/cgo package,
    so don't try to depend on it (as it happens, this fixes golang/go#25324).
    
    The result is that the cmd/go vet tests pass when using -compiler=gccgo.
    
    Reviewed-on: https://go-review.googlesource.com/114516

From-SVN: r260913
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Milestone
Go1.11
Development

No branches or pull requests
3 participants
@siebenmann @ianlancetaylor @gopherbot