Skip to content

cmd/go: gccgo and GOROOT not quite there yet #3246

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
Closed
alberts opened this issue Mar 8, 2012 · 24 comments
Closed

cmd/go: gccgo and GOROOT not quite there yet #3246

alberts opened this issue Mar 8, 2012 · 24 comments
Labels
FrozenDueToAge

Comments

@alberts
Copy link
Contributor

alberts commented Mar 8, 2012 

What steps will reproduce the problem?

I have a directory with some subrepos and goprotobuf:

deps/src/code.google.com/p/go.crypto
deps/src/code.google.com/p/go.net
deps/src/code.google.com/p/goprotobuf

cd ~/deps

GOROOT=/opt/gccgo GOPATH=~/deps go install -v -compiler=gccgo ./...

doesn't work.

What do you see instead?

package code.google.com/p/go.crypto/bcrypt
imports runtime: import "runtime": cannot find package

etc.


Which compiler are you using (5g, 6g, 8g, gccgo)?

gccgo

Which operating system are you using?

linux

Which revision are you using?  (hg identify)

$ go version
go version weekly.2012-03-04 +ee68d043e7f5

$ gccgo --version
gccgo (GCC) 4.8.0 20120308 (experimental)

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@185094
138bc75d-0d04-0410-961f-82ee72b054a4

Please provide any additional information below.

My gccgo GOROOT looks like this:

/opt/gccgo/libexec/gcc/x86_64-redhat-linux/4.8.0/plugin
/opt/gccgo/libexec/gcc/x86_64-redhat-linux/4.8.0/install-tools
/opt/gccgo/include/c++/4.8.0
/opt/gccgo/bin
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/path
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/debug
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/regexp
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/archive
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/text
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/text/template
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/testing
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/mime
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/log
...
/opt/gccgo/lib
/opt/gccgo/lib/gcc
/opt/gccgo/lib/gcc/x86_64-redhat-linux
/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0
/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/include
/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/include/ssp
/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/32
/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/include-fixed
/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/include-fixed/linux
/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/plugin
/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/plugin/include
/opt/gccgo/lib/go/4.8.0/x86_64-redhat-linux
/opt/gccgo/lib/go/4.8.0/x86_64-redhat-linux/path
/opt/gccgo/lib/go/4.8.0/x86_64-redhat-linux/debug
/opt/gccgo/lib/go/4.8.0/x86_64-redhat-linux/regexp
/opt/gccgo/lib/go/4.8.0/x86_64-redhat-linux/archive
/opt/gccgo/lib/go/4.8.0/x86_64-redhat-linux/text
/opt/gccgo/lib/go/4.8.0/x86_64-redhat-linux/text/template
...
/opt/gccgo/share/man/man1
/opt/gccgo/share/man/man3
/opt/gccgo/share/man/man7
/opt/gccgo/share/locale
/opt/gccgo/share/info
/opt/gccgo/share/gcc-4.8.0/python/libstdcxx
/opt/gccgo/share/gcc-4.8.0/python/libstdcxx/v6

I have configured the gccgo build almost exactly like Fedora does it, with /usr ->
/opt/gccgo:

CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic'
CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic'
prefix=/opt/gccgo
./configure --prefix=$prefix --mandir=$prefix/share/man --infodir=$prefix/share/info
--disable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release
--disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,go,lto
--enable-plugin --enable-initfini-array --disable-dssi --with-ppl --with-cloog
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux

I seems this builds 32-bit and 64-bit compilers. It would be useful if setting
GOARCH=386 actually made the go tool pass -m32 to gccgo. The same for -m64 with
GOARCH=amd64.
@rsc
Copy link
Contributor

rsc commented Mar 8, 2012

Comment 1:

"""
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/path
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/debug
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/regexp
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/archive
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/text
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/text/template
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/testing
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/mime
/opt/gccgo/lib64/go/4.8.0/x86_64-redhat-linux/log
"""
This is a completely different layout than the go tool expects.
If you run
GOROOT=/opt/gccgo go list -compiler=gccgo -json -e text/template
you should be able to see the expected target file, which
is along the lines of $GOROOT/pkg/gccgo/text/libtemplate.a.
I have no idea how the go tool is supposed to get from /opt/gccgo
to this new archive list; maybe it should just assume that the
known packages are there without any check for a target at all,
but then it needs a list of known packages.
What are other people doing?  remy, minux?

@alberts
Copy link
Contributor Author

alberts commented Mar 8, 2012

Comment 2:

Some more output from this gccgo build if that helps:
$ gccgo -m32 -print-file-name=libgo.so
/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/../../../../lib/libgo.so
$ gccgo -m64 -print-file-name=libgo.so
/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/../../../../lib64/libgo.so
$ gccgo -print-search-dirs
install: /opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/
programs:
=/opt/gccgo/libexec/gcc/x86_64-redhat-linux/4.8.0/:/opt/gccgo/libexec/gcc/x86_64-redhat-linux/4.8.0/:/opt/gccgo/libexec/gcc/x86_64-redhat-linux/:/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/:/opt/gccgo/lib/gcc/x86_64-redhat-linux/:/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/../../../../x86_64-redhat-linux/bin/x86_64-redhat-linux/4.8.0/:/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/../../../../x86_64-redhat-linux/bin/
libraries:
=/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/:/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/../../../../x86_64-redhat-linux/lib/x86_64-redhat-linux/4.8.0/:/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/../../../../x86_64-redhat-linux/lib/../lib64/:/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/../../../x86_64-redhat-linux/4.8.0/:/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/../../../../lib64/:/lib/x86_64-redhat-linux/4.8.0/:/lib/../lib64/:/usr/lib/x86_64-redhat-linux/4.8.0/:/usr/lib/../lib64/:/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/../../../../x86_64-redhat-linux/lib/:/opt/gccgo/lib/gcc/x86_64-redhat-linux/4.8.0/../../../:/lib/:/usr/lib/

@alberts
Copy link
Contributor Author

alberts commented Mar 8, 2012

Comment 3:

FWIW, here's a look into the contents of the current Fedora gcc go packages for 4.7.0:
gcc-go: http://koji.fedoraproject.org/koji/rpminfo?rpmID=2985972
libgo: http://koji.fedoraproject.org/koji/rpminfo?rpmID=2985997
libgo-devel: http://koji.fedoraproject.org/koji/rpminfo?rpmID=2985974

@remyoudompheng
Copy link
Contributor

Comment 4:

There could be multiple ways of fixing. I didn't bother yet because I always have the
usual Go tree installed: otherwise I wouldn't have a go command.

@alberts
Copy link
Contributor Author

alberts commented Mar 8, 2012

Comment 5:

I also have the usual Go tree installed, but it's not clear how it's supposed to
interact with building with gccgo.
Does gccgo need GOROOT to be set at all?
When building with -compiler=gccgo, can't GOROOT be ignored entirely?
It doesn't really make sense to try to rebuild "std" packages if they're missing, since
gccgo will usually be installed to a read-only system location.
This is probably also true for when the [568]g distribution gets installed to a system
location. A missing "std" package in this case should just be an error.

@ianlancetaylor
Copy link
Member

Comment 6:

gccgo ignores GOROOT.
At this point I don't know how the gccgo path layout should work with the go program. 
The gccgo path layout is guided by gcc conventions, not Go ones.  Of course this only
matters for the standard packages.

@dsymonds
Copy link
Contributor

dsymonds commented Mar 8, 2012

Comment 7:

Labels changed: added priority-go1, gccgo, toolbug, removed priority-triage.

Owner changed to @ianlancetaylor.

@alberts
Copy link
Contributor Author

alberts commented Mar 10, 2012

Comment 8:

There's another issue here.
The following mostly works if you have a GOROOT to appease the go tool to the point that
it builds with gccgo:
go test -compiler=gccgo -gccgoflags --coverage -v -work ./...
but with benchmarks added, there's some errors:
go test -compiler=gccgo -gccgoflags --coverage -v -work -test.bench=. ./...
E.g., with my experiment of building parts of the 6g standard library with gccgo, I see
stuff like:
=== RUN TestReader-16
--- PASS: TestReader-16 (0.00 seconds)
=== RUN TestPartialRead-16
--- PASS: TestPartialRead-16 (0.00 seconds)
=== RUN TestIncrementalRead-16
--- PASS: TestIncrementalRead-16 (0.00 seconds)
=== RUN TestNonSeekable-16
--- PASS: TestNonSeekable-16 (0.00 seconds)
=== RUN TestWriter-16
--- PASS: TestWriter-16 (0.82 seconds)
PASS
ok      std/archive/tar 0.833s
# testmain
gccgo: error: : No such file or directory
FAIL    std/archive/zip [build failed]
# testmain
gccgo: error: : No such file or directory
gccgo: error: $WORK/std/archive/zip/_test/zip.test: No such file or directory
gccgo: error: : No such file or directory
FAIL    std/bufio [build failed]
Also, it doesn't seem as if the "building out-of-date packages" warning is displayed
more than once, although I think it should.

@alberts
Copy link
Contributor Author

alberts commented Mar 10, 2012

Comment 9:

There's also an issue with cgo packages:
go install -compiler=gccgo -v somecgopkg
somecgopkg
exec: "": executable file not found in $PATH
I suspect it's not looking for cgo in the right tool directory.
Tested with weekly.2012-03-04 +3355c03e3e2c.

@remyoudompheng
Copy link
Contributor

Comment 10:

I've tried including a fix in CL http://golang.org/cl/5797046/

@alberts
Copy link
Contributor Author

alberts commented Mar 16, 2012

Comment 11:

Can't compile latest go.crypto or goprotobuf.
https://groups.google.com/d/msg/golang-dev/CDWldKSFOeg/kJzfLhklV8IJ
https://groups.google.com/d/msg/golang-dev/ODBBMvFuEOE/pa0gMD72E2sJ

@ianlancetaylor
Copy link
Member

Comment 12:

Not sure what's going on here but it's not going to be fixed for Go 1.

Labels changed: added priority-later, removed priority-go1.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 13:

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 14:

Labels changed: added go1.1maybe.

@rsc
Copy link
Contributor

rsc commented Mar 12, 2013

Comment 15:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 16:

Labels changed: added go1.2maybe.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 17:

Labels changed: added feature.

@robpike
Copy link
Contributor

robpike commented Aug 29, 2013

Comment 18:

Won't happen for 1.2.

Labels changed: removed go1.2maybe.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 19:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 20:

Labels changed: removed feature.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 21:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 22:

Labels changed: added repo-gccgo.

@ianlancetaylor
Copy link
Member

Comment 23:

As far as I can tell, this works now.
If we still have problems, let's open specific issues for specific problems.  Please
don't re-open this general issue again.

Status changed to Fixed.

@davecheney
Copy link
Contributor

Comment 24:

I agree. Michael and I have put some work into cmd/go this cycle and it's certainly
better wrt. gccgo than it was previously.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@davecheney @dsymonds @rsc @remyoudompheng @alberts @ianlancetaylor @robpike @gopherbot