I have confirmed that the bug was fixed upstream with revision https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=221643
@doko, is it possible to get this patch into V ? On Wed, Mar 25, 2015 at 10:32 AM, Bug Watch Updater <1432...@bugs.launchpad.net> wrote: > Launchpad has imported 9 comments from the remote bug at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65462. > > If you reply to an imported comment from within Launchpad, your comment > will be sent to the remote bug automatically. Read more about > Launchpad's inter-bugtracker facilities at > https://help.launchpad.net/InterBugTracking. > > ------------------------------------------------------------------------ > On 2015-03-18T19:37:59+00:00 Boger-e wrote: > > When using the go tool provided with gccgo in gcc 5.0, the use of 'go > get' doesn't always find and build the dependent packages correctly. > > Here is an example: > > go get -u github.com/mitchellh/gox > > There is a dependent package github.com/mitchellh/iochan but that never > gets downloaded or built and as a result neither does > github.com/mitchellh/gox. I can make it work by downloading them in > separate steps this way: > > go get -u github.com/mitchellh/uchan > go get -u github.com/mitchellh/gox > > > After further debugging I found the problem has to do with the code in > libgo/go/cmd/go/pkg.go in the load function where it does this check: > > .... > > > p1 := loadImport(path, p.Dir, stk, p.build.ImportPos[path]) > if !reqPkgSrc && p1.Root == "" { > continue > } > > .... > > > When it tries to load the github.com/mitchellh/uchan package, p1.Root == "" > so it skips the rest of the code in the loop that loads the package. Isn't > this a case where p1.Root should have a non-null string and therefore not > continue/skip the rest of the body of the loop and get it loaded? > > Reply at: > https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1432497/comments/3 > > ------------------------------------------------------------------------ > On 2015-03-20T16:58:23+00:00 Boger-e wrote: > > Created attachment 35077 > Fix dependencies in go tool for gccgo > > The code to determine when to import packages was not quite catching the > cases it should. It really needs to know what packages are part of the > GO standard packages and not try to load those -- if they aren't then > they should be loaded. > > This makes a few changes to the previous: > - change the name of reqPkgSrc to reqStdPkgSrc to indicate when we should > require the source for GO standard packages when loading packages. > - generate the list of standard packages found in libgo and make that > available to build into the go tool > - set the flag Standard in the Package structure correctly for gccgo, based > on the list of expected libgo standard packages > - use the reqStdPkgSrc flag and the package.Standard flag to determine if the > load of the package should be attempted > > Reply at: > https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1432497/comments/5 > > ------------------------------------------------------------------------ > On 2015-03-20T20:08:18+00:00 Boger-e wrote: > > Created attachment 35081 > Updated patch to add unsafe to the list of std package names > > Reply at: > https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1432497/comments/6 > > ------------------------------------------------------------------------ > On 2015-03-20T20:10:43+00:00 Ian Lance Taylor wrote: > > Can you send the libgo part of this patch through the codereview site? > > Reply at: > https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1432497/comments/7 > > ------------------------------------------------------------------------ > On 2015-03-20T20:31:21+00:00 Boger-e wrote: > > Do you mean as if submitting to gofrontend-dev? > > Reply at: > https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1432497/comments/8 > > ------------------------------------------------------------------------ > On 2015-03-20T20:44:52+00:00 Ian Lance Taylor wrote: > > Yes, I did mean for gofrontend-dev. > > Or if you want to submit to the master sources, that is even better; > guidelines are at http://golang.org/doc/contribute.html . > > Reply at: > https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1432497/comments/9 > > ------------------------------------------------------------------------ > On 2015-03-20T21:03:26+00:00 Boger-e wrote: > > I decided that you meant the gofrontend so here it is (just did the hg > mail) > > https://codereview.appspot.com/213570043/ > > Reply at: > https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1432497/comments/10 > > ------------------------------------------------------------------------ > On 2015-03-24T19:51:02+00:00 I-ian-1 wrote: > > Author: ian > Date: Tue Mar 24 19:50:31 2015 > New Revision: 221643 > > URL: https://gcc.gnu.org/viewcvs?rev=221643&root=gcc&view=rev > Log: > PR go/65462 > cmd: Fix dependencies for 'go get' with gccgo > > Problem described in GCC BZ 65462. > Generate the list of the standard GO package names based on what was built > into libgo in the libgo Makefile. > Change the var name from reqPkgSrc to reqStdPkgSrc to clarify it only affects > standard GO packages. > Skip the attempted loading of a package only if it is a standard GO package > and the flag is set indicating its source is not required to be available. > This requires a corresponding change to gotools to build and link in the new > file containing the list of standard GO package names that was generated by > the libgo Makefile. > > gotools/: > PR go/65462 > * Makefile.am (go_cmd_go_files): Add $(libgodir)/zstdpkglist.go. > * Makefile.in: Rebuild. > > Modified: > trunk/gotools/ChangeLog > trunk/gotools/Makefile.am > trunk/gotools/Makefile.in > trunk/libgo/Makefile.am > trunk/libgo/Makefile.in > trunk/libgo/go/cmd/go/build.go > trunk/libgo/go/cmd/go/pkg.go > trunk/libgo/go/cmd/go/test.go > > Reply at: > https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1432497/comments/13 > > ------------------------------------------------------------------------ > On 2015-03-24T20:25:50+00:00 Ian Lance Taylor wrote: > > Fixed now, I hope. > > Reply at: > https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1432497/comments/14 > > > ** Changed in: gcc > Status: Unknown => Fix Released > > ** Changed in: gcc > Importance: Unknown => Medium > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1432497 > > Title: > /usr/bin/go-5 does not recursively go get packages > > Status in The GNU Compiler Collection: > Fix Released > Status in gccgo-5 package in Ubuntu: > Incomplete > > Bug description: > The version of the Go tool shipped with gccgo 5.0 does not correctly > recursively download dependencies of a package > > dfc@ubuntu:~$ dpkg -S $(which go-5) > gccgo-5: /usr/bin/go-5 > dfc@ubuntu:~$ go get -u -v -d github.com/juju/juju/... > github.com/juju/juju (download) > > This is wrong. The correct operation would be to inspect all the code > in $GOPATH/src/github.com/juju/juju/ and recursively fetch the > dependencies. > > The proper operation should look like > > lucky(~/devel/FlameGraph) % go get -u -v -d github.com/juju/juju/... > github.com/juju/juju (download) > code.google.com/p/go.crypto (download) > code.google.com/p/go.net (download) > github.com/coreos/go-systemd (download) > github.com/godbus/dbus (download) > github.com/dustin/go-humanize (download) > github.com/juju/blobstore (download) > github.com/juju/errors (download) > github.com/juju/loggo (download) > .. list continues for hundreds more lines > > To manage notifications about this bug go to: > https://bugs.launchpad.net/gcc/+bug/1432497/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1432497 Title: /usr/bin/go-5 does not recursively go get packages To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/1432497/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
