Ok thanks I saw that post but didn't read down far enough, I am using golang v1.8 and GCC-7.0 and most of the refs in that post were golang v1.6 and GCC-6.x. At the tail end there was some refs to golang v1.7 &v1.8 as you say. Issue has been around for almost a year I guess.
Ended up switching to gc don't have the cycles to contrib to a fix right now. Hate to do that, I have been a GCC user for years. Thanks again for your help. BR, Rich On Monday, March 20, 2017 at 7:26:41 PM UTC-4, Ian Lance Taylor wrote: > > On Mon, Mar 20, 2017 at 4:25 PM, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > > On Mon, Mar 20, 2017 at 4:17 PM, Richard D'Addio <rgda...@gmail.com > <javascript:>> wrote: > >> With gccgo I get the following error the same builds fine with gc: > >> > >> //with native > >> > >> > /home/rdaddio/mynewclient/clone_gobotics/gobotics/go/pkg/tool/linux_amd64/compile > > > >> -o $WORK/github.com/hashicorp/go-multierror.a -trimpath $WORK -p > >> github.com/hashicorp/go-multierror -complete -buildid > >> e777c32e05670dbca9940409bba89b18504d68f5 -importmap > >> > github.com/hashicorp/errwrap=github.com/hashicorp/go-multierror/vendor/github.com/hashicorp/errwrap > > >> -D > >> _/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/ > github.com/hashicorp/go-multierror > >> -I $WORK -I > >> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/pkg/linux_amd64 > -pack > >> ./append.go ./flatten.go ./format.go ./multierror.go ./prefix.go > >> > >> > >> //with gccgo option > >> > >> /home/rdaddio/myGCC_run/myGCC_out/bin/gccgo -I $WORK -I > >> > /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/pkg/gccgo_linux_amd64 > >> -c -g -m64 -fgo-pkgpath=github.com/hashicorp/go-multierror > >> > -fgo-relative-import-path=_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/ > github.com/hashicorp/go-multierror > >> -o $WORK/github.com/hashicorp/go-multierror/_obj/_go_.o ./append.go > >> ./flatten.go ./format.go ./multierror.go ./prefix.go > >> > >> mkdir -p $WORK/github.com/pkg/ > >> > >> cd > >> /home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/ > github.com/pkg/errors > >> > >> /home/rdaddio/myGCC_run/myGCC_out/bin/gccgo -I $WORK -c -g -m64 > >> -fgo-pkgpath=github.com/pkg/errors > >> > -fgo-relative-import-path=_/home/rdaddio/mynewclient/clone_gobotics/gobotics/lib/src/ > github.com/pkg/errors > >> -o $WORK/github.com/pkg/errors/_obj/_go_.o ./errors.go ./stack.go > >> > >> # github.com/hashicorp/go-multierror > >> > >> lib/src/github.com/hashicorp/go-multierror/prefix.go:6:30: error: > import > >> file 'github.com/hashicorp/errwrap' not found > >> > >> "github.com/hashicorp/errwrap" > >> > >> ^ > >> > >> lib/src/github.com/hashicorp/go-multierror/prefix.go:30:20: error: > reference > >> to undefined name 'errwrap' > >> > >> err.Errors[i] = errwrap.Wrapf(format, e) > >> > >> ^ > >> > >> lib/src/github.com/hashicorp/go-multierror/prefix.go:35:10: error: > reference > >> to undefined name 'errwrap' > >> > >> return errwrap.Wrapf(format, err) > > > > > > Thanks. It looks like there is a bug with the implementation of > > vendor directories when using -compiler=gccgo. > > In fact it's already been reported as https://golang.org/issue/15628. > > Ian > > > >> On Monday, March 20, 2017 at 6:53:53 PM UTC-4, Ian Lance Taylor wrote: > >>> > >>> On Mon, Mar 20, 2017 at 3:40 PM, Richard D'Addio <rgda...@gmail.com> > >>> wrote: > >>> > Sorry in advance if this is the wrong list for this. > >>> > > >>> > > >>> > I can build the gobot.io code below with the golang v1.8 and the > >>> > standard > >>> > compiler: > >>> > > >>> > go version go1.8 linux/amd64 > >>> > > >>> > go build -work -x hello_blink.go > >>> > > >>> > > >>> > But when I try to build with the GCC option in the same scenario it > >>> > fails. I > >>> > am using GCC > >>> > > >>> > gccgo (GCC) 7.0.1 20170314 (experimental) which has go1.8 support & > all > >>> > paths are correct: > >>> > > >>> > go build -work -x -compiler gccgo hello_blink.go > >>> > > >>> > > >>> > It can't seem to find paths that the gc code found and this leads to > a > >>> > link > >>> > error. The problem is > >>> > > >>> > in a single file and if this file is commented out the code builds > and > >>> > runs. > >>> > Since this code is likely unused > >>> > > >>> > it might be that the native compiler is detecting that > automatically? > >>> > > >>> > > >>> > It didn't seem like any special options were needed to use the gccgo > >>> > compiler. I've used > >>> > > >>> > it elsewhere in a similar way (different go code of course) without > >>> > problems. > >>> > >>> You didn't tell us what actually happens. How does it fail? > >>> > >>> Ian > >> > >> -- > >> 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...@googlegroups.com <javascript:>. > >> For more options, visit https://groups.google.com/d/optout. > -- 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.
