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/cgo: unknown ptrSize for $GOARCH mips when using gccgo #7398

Closed
gopherbot opened this issue Feb 24, 2014 · 13 comments
Closed

cmd/cgo: unknown ptrSize for $GOARCH mips when using gccgo #7398

gopherbot opened this issue Feb 24, 2014 · 13 comments
Labels
FrozenDueToAge
Milestone
Unplanned

Comments

@gopherbot
Copy link
Contributor

by erik.westrup:

In a cross-compilaton situation targeting a MIPS running device from my amd64 
host I want to be able to run cgo. However cgo does not seems to be adjusted to 
handle the architectures that gccgo supports. More specifically 
src/cmd/cgo/main.go:132 only accepts the architectures that are supported by 
gc. I expect that, if I compile cgo with gccgo, that the correct architectures 
should be supported, just like when you compile the Go tool with gccgo. 

What steps will reproduce the problem?
1. Follow the steps to build a cross-compiler and the go tool with gccgo 
   (binary named xgo here), as documented in a new wikipage I wrote: 
   http://code.google.com/p/go-wiki/wiki/GccgoCrossCompilation
2.  $ cd ~/tmp/go/src/cmd/cgo # the copy of the repo that is outside $GOROOT
    $ go build -o xcgo -compiler gccgo .
    $ ln -s xcgo cgo
    $ export PATH="$(pwd):$PATH"
3. Save simple program using C to disk: http://play.golang.org/p/smQwaB0dfG
4.  $ CGO_ENABLED=1 GOARCH=mips xgo build -x -compiler gccgo goctest
    WORK=/tmp/go-build946830148
    mkdir -p $WORK/goctest/_obj/
    mkdir -p $WORK/goctest/_obj/exe/
    cd /home/erikw/dev/go/src/goctest
    /home/erikw/src/go/pkg/tool/linux_amd64/cgo -objdir $WORK/goctest/_obj/ -gccgo -- -I $WORK/goctest/_obj/ goc.go
    # goctest
    unknown ptrSize for $GOARCH "mips"

What is the expected output?
    No errors from cgo, as cgo is compiled with gccgo.


What do you see instead?
    A compiled program with cgo generating .[ch]-files as is done when using a 
    gc-supported $GOARCH.


Which operating system are you using?
    Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux

Which version are you using?  (run 'go version' or 'gccgo --version')
    go version devel +7f2863716967 Tue Feb 18 16:48:34 2014 +1100 linux/amd64
    gccgo (GCC) 4.9.0 20131127 (experimental)

Please provide any additional information below.
    Discussion leading up to this issue can be found at
    "[golang-nuts] Simplification of MIPS cross-compilation?" 
    https://groups.google.com/forum/#!topic/golang-nuts/PgyS2yoO2jM
@gopherbot
Copy link
Contributor Author

Comment 1 by erik.westrup:

Put this on hold until I've investigated some more, turns out that the actual gccgo
version in use is:
gccgo (crosstool-NG 1.19.0) 4.8.1

@ianlancetaylor
Copy link
Member

Comment 2:

Labels changed: added repo-main, release-go1.3.

Status changed to Accepted.

@gopherbot
Copy link
Contributor Author

Comment 3 by erik.westrup:

Ignore that last comment. This issue is still valid, again tested today with the most
recent versions:
$ go version
go version devel +32c32aef2a41 Thu Mar 20 07:28:24 2014 +0100 linux/amd64
$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=/home/erikw/bin/gccgo/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/erikw/bin/gccgo --enable-languages=c,c++,go
Thread model: posix
gcc version 4.9.0 20140307 (experimental) (GCC)

@rsc
Copy link
Contributor

rsc commented Apr 3, 2014

Comment 4:

I don't see this happening for 1.3.

Labels changed: added release-go1.4, removed release-go1.3.

@gopherbot
Copy link
Contributor Author

Comment 5 by erik.westrup:

That's unfortunate. 
However can we clarify the issue a bit? In the thread "[golang-nuts] Simplification of
MIPS cross-compilation?" Dave Cheney revealed that you have to build the go-tool using
gccgo to get a version that supports the same target architectures that (a
cross-compiling) gccgo supports. The problem with current versions of the packages
(tested today with tip of the repos) (versions attached below!) is that some code has to
be out-commented to pass the compilation (as mentioned in the golang-nuts thread) and
that compilation with the produced xgo-binary ends with the 'unknown ptrSize for $GOARCH
"mips"' error.
What is unclear though about the problem is if the go/src/cmd/cgo tool also has to be
compiled with gccgo producing a xcgo in the same manner like xgo? I assumed so when
posting this issue based on the output from $(xgo build -compiler -x ...) showing that
the command complaining about the pointer size is cgo.
Whether or not cgo also should be compiled with gccgo this issue is still valid as of
today, since xgo can not be compiled without commenting out code. But it would be nice
to know if cgo has to be compiled using gccgo libraries too. Anyone know? 
ping {iant, cheney}
Versions I used today (tip of repos):
$ go version
go version devel +e426bfa69c19 Fri Apr 04 08:42:35 2014 +0200 + linux/amd64
$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=/home/erikwp/bin/gccgo/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/erikwp/bin/gccgo --enable-languages=c,c++,go
Thread model: posix
gcc version 4.9.0 20140307 (experimental) (GCC)
$ mipsel-unknown-linux-gnu-gccgo -v
Using built-in specs.
COLLECT_GCC=./mipsel-unknown-linux-gnu-gccgo
COLLECT_LTO_WRAPPER=/home/erikwp/src/mipsel-unknown-linux-gnu_gcc_build_newest/tools/libexec/gcc/mipsel-unknown-linux-gnu/4.9.0/lto-wrapper
Target: mipsel-unknown-linux-gnu
Configured with:
/home/erikwp/src/mipsel-unknown-linux-gnu_gcc_build_newest/src/gccgo/configure
--prefix=/home/erikwp/src/mipsel-unknown-linux-gnu_gcc_build_newest/tools
--target=mipsel-unknown-linux-gnu --build=amd64-linux-gnu --host=amd64-linux-gnu
--with-sysroot=/home/erikwp/src/mipsel-unknown-linux-gnu_gcc_build_newest/sysroot
--enable-languages=c,c++,go --disable-libssp --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libquadmath-support --with-pkgversion='erikwp'\''s
mipsel-unknown-linux-gnu GCC phase3 crosscompiler' --with-ppl=no --with-isl=no
--with-cloog=no --with-libelf=no
Thread model: posix
gcc version 4.9.0 20140307 (experimental) (erikwp's mipsel-unknown-linux-gnu GCC phase3
crosscompiler)

@rsc
Copy link
Contributor

rsc commented Sep 15, 2014

Comment 6:

I think it would be fine to change the gccgo cgo to know about mips but I don't think
the gc toolchain should change until gc supports mips.

Labels changed: added release-none, removed release-go1.4.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@gumorxmt
Copy link

gumorxmt commented Jun 1, 2016

I had the similar problem when I was trying to compiler docker using gccgo on Tilera CPU architecture. it reports like
unknown ptrSize for $GOARCH tilegx
I solved this problem by updating
diff ./src/libgo/go/cmd/cgo/main.go ./main.go.origin
139d138
< "tilegx": 8,
149d147
< "tilegx": 8,
Hope this works for your issue.

@ianlancetaylor
Copy link
Member

This is actually fixed (for MIPS, not for tliegx).

@a13xb
Copy link

a13xb commented Jul 13, 2016

@rsc Is there such a thing as "gccgo cgo"? cgo in gc already supports gccgo as a backend (#2313), hence should recognise architectures that gccgo supports.

@ianlancetaylor Do you mean it's fixed for mips64, not mips, correct?

@ianlancetaylor
Copy link
Member

gccgo has its own version of cgo. This issue is fixed in gccgo's version.

@a13xb
Copy link

a13xb commented Jul 13, 2016

The gc version explicitly supports gccgo, shouldn't it support gccgo architectures (or not support gccgo at all)?

@a13xb
Copy link

a13xb commented Jul 13, 2016

To follow up on that...

The main issue is that there seems to be no way to invoke alternative cgo when compiling using the go tool (which gccgo does not have). It will always pick the executable from GOROOT.

@ianlancetaylor
Copy link
Member

@a13xb There isn't a great solution here. Yes, ideally, the gc cgo tool should support the targets that gccgo supports, but that depends on your version of gccgo and it can not realistically be kept up to date.

In any case, I think you should open a new issue for this, as this one is closed.

@golang golang locked and limited conversation to collaborators Jul 13, 2017
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
Unplanned
Development

No branches or pull requests
5 participants
@rsc @a13xb @ianlancetaylor @gopherbot @gumorxmt