cmd/cgo: cannot use clang 3.2 to compile cgo packages #4829

davecheney · 2013-02-17T01:00:51Z

What steps will reproduce the problem?

% $CC -v
clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

./all.bash 

...

# net
clang: error: argument unused during compilation: '-fno-eliminate-unused-debug-types'
debug/gosym
encoding/csv
exp/ebnf
go/types
exp/inotify
exp/ebnflint
exp/norm
image/gif
image/jpeg
image/png
os/user
# os/user
clang: error: argument unused during compilation: '-fno-eliminate-unused-debug-types'

If cmd/cgo is modified to aboid passing -fno-eliminate-unused-debug-types when $CC ==
clang then the following error is received

# net
reading DWARF entry: decoding dwarf section info at offset 0x45: unknown entry attr
format
debug/gosym
encoding/csv
database/sql
exp/ebnf
go/types
exp/ebnflint
exp/inotify
exp/norm
image
image/draw
image/gif
image/jpeg
image/png
os/user
runtime/debug
# os/user
reading DWARF entry: decoding dwarf section info at offset 0x45: unknown entry attr
format

Please use labels and text to provide additional information.

mewmew · 2013-02-17T05:43:46Z

Comment 1:

Initial work has been started in CL 7354043.
It resolves the following errors:
* "clang: error: argument unused during compilation: '-fno-eliminate-unused-debug-types'"
* "reading DWARF entry: decoding dwarf section info at offset 0x45: unknown entry attr
format"
The upstream issue for "-fno-eliminate-unused-debug-types" is being tracked at
http://llvm.org/bugs/show_bug.cgi?id=11710
After those two errors are fixed the following errors are encountered:
./all.bash 
...
# net
cgo_unix.go:45:8: error: field has incomplete type 'void'
                void p0;
                     ^
cgo_unix.go:46:8: error: field has incomplete type 'void'
                void p1;
                     ^
cgo_unix.go:47:8: error: field has incomplete type 'void'
                void p2;
                     ^
cgo_unix.go:48:8: error: field has incomplete type 'void'
                void p3;
                     ^
cgo_unix.go:61:8: error: field has incomplete type 'void'
                void p0;
                     ^
cgo_unix.go:71:8: error: field has incomplete type 'void'
                void p0;
                     ^
cgo_unix.go:83:8: error: field has incomplete type 'void'
                void r;
                     ^
cgo_unix.go:92:8: error: field has incomplete type 'void'
                void p0;
                     ^
cgo_unix.go:93:8: error: field has incomplete type 'void'
                void p1;
                     ^
cgo_unix.go:94:8: error: field has incomplete type 'void'
                void p2;
                     ^
cgo_unix.go:95:8: error: field has incomplete type 'void'
                void p3;
                     ^
11 errors generated.
index/suffixarray
runtime/pprof
text/scanner
...
math/cmplx
os/user
runtime/debug
testing
testing/iotest
testing/quick
# os/user
lookup_unix.go:55:8: error: field has incomplete type 'void'
                void p0;
                     ^
lookup_unix.go:65:8: error: field has incomplete type 'void'
                void p0;
                     ^
lookup_unix.go:66:8: error: field has incomplete type 'void'
                void p1;
                     ^
lookup_unix.go:67:8: error: field has incomplete type 'void'
                void p2;
                     ^
lookup_unix.go:69:8: error: field has incomplete type 'void'
                void p4;
                     ^
lookup_unix.go:81:8: error: field has incomplete type 'void'
                void r;
                     ^
lookup_unix.go:91:8: error: field has incomplete type 'void'
                void p1;
                     ^
lookup_unix.go:92:8: error: field has incomplete type 'void'
                void p2;
                     ^
lookup_unix.go:95:8: error: field has incomplete type 'void'
                void p4;
                     ^
9 errors generated.

minux · 2013-02-17T15:47:00Z

Comment 2:

I've got another fix for the unused argument problem:
https://golang.org/cl/7351044
all.bash passed on FreeBSD 9/AMD64 with:
$ clang -v
FreeBSD clang version 3.0 (branches/release_30 142614) 20111021
Target: x86_64-unknown-freebsd9.0
Thread model: posix

minux · 2013-02-17T21:30:32Z

Comment 3:

@rsc, @iant, please see the description of https://golang.org/cl/7351044.
Is that a real bug of clang?
with clang, one can't differentiate between:
void *malloc(size_t);
and
void *malloc(long unsigned int);
If it's not a bug, how can we workaround this problem?
FYI:
in the Go standard library, there is exact one C.malloc(C.size_t(number)) invocation:
# os/user
lookup_unix.go:64: cannot use _Ctype_size_t(bufSize) (type C.size_t) as type C.ulong in
function argument

minux · 2013-02-17T21:32:34Z

Comment 4:

in case the description changes, the way to reproduce the "bug" is:
$ cat x.c
#include <stdlib.h>
typeof(malloc) *pointer;
$ clang -o x-clang.o -gdwarf-2 -c x.c # clang version 3.3 (http://llvm.org/git/clang.git
e50e91d4a6f6c) (http://llvm.org/git/llvm.git 906727dcfeb)
$ gcc -o x-gcc.o -gdwarf-2 -c x.c # gcc version 4.8.0 20130129 (experimental) (GCC)
Then compare DWARF info. in two object files, and you will discover that
clang generates this type for pointer: *func (long unsigned int) *void
while gcc (correctly) generates this:
*func (size_t) *void

ianlancetaylor · 2013-02-17T22:16:13Z

Comment 5:

That looks like a clang bug to me.  Admittedly it's a difference that makes no
difference in C/C++.  Still, debug info should provide the correct type.

minux · 2013-02-19T16:58:51Z

Comment 6:

This issue was updated by revision 7fdaec6.

R=minux.ma, iant
CC=dave, golang-dev
https://golang.org/cl/7354043
Committer: Shenghou Ma

minux · 2013-02-19T17:01:40Z

Comment 7:

iant, what's your opinion regarding my CL?
should I delay it until the clang bug is fixed?
(i will try to fix that by myself before reporting it upstream)

ianlancetaylor · 2013-02-20T02:42:20Z

Comment 8:

I don't see a need to delay the CL, it seems like the CL is an
improvement in any case.
Ian

mewmew · 2013-02-20T15:50:22Z

Comment 9:

After applying CL 7351044 the build succeeds and all package tests pass, but
afterwards it outputs the following error:
# ../doc/progs
# command-line-arguments
could not determine kind of name for C.stdout
for the following two files:
   doc/progs/cgo3.go
   doc/progs/cgo4.go
I tried the following workaround:
https://code.google.com/p/go/source/browse/misc/cgo/stdio/stdio.go
Now the ./all.bash completes with:
"ALL TESTS PASSED"
Thanks for your work on solving this issue!

minux · 2013-02-23T12:25:03Z

Comment 10:

This issue was updated by revision eec9614.

This should fix most parts of the problem, but one glitch still remains.
DWARF generated by newer clang doesn't differentiate these
two function types:
    void *malloc(size_t);
    void *malloc(unsigned long int);
so you might need to do this to make make.bash pass:
sed -i -e 's/C.malloc(C.size_t/C.malloc(C.ulong/' pkg/os/user/lookup_unix.go
R=golang-dev, dave, iant, rsc
CC=golang-dev
https://golang.org/cl/7351044

minux · 2013-02-23T12:38:30Z

Comment 11:

on Darwin/amd64, all.bash takes:
with gcc (version 4.2.1 (Apple Inc. build 5666) (dot 3)):
197.96 real       350.98 user        90.61 sys
with clang (Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn)):
182.91 real       323.11 user        88.28 sys
I wonder if we can switch the darwin builder and freebsd builder to clang?
could someone who has installed the latest xcode clang help testing the size_t
issue mentioned in the last comment?
I only have a rather old version of clang (pre 3.0).

davecheney · 2013-02-23T12:40:59Z

Comment 12:

I have a patch to the builder which will pass through $CC if set
waiting to submit. I'll do so this weekend.

davecheney · 2013-02-23T12:46:00Z

Comment 13:

LGTM,
odessa(~/go/src) % hg id
04d884e0f760 tip
odessa(~/go/src) % uname -a
Darwin odessa.fritz.box 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug
23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
odessa(~/go/src) % $CC -v
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

minux · 2013-02-23T12:52:24Z

Comment 14:

before we switch the builder, i'd like to know if latest clang shipped by apple in xcode
is also affected by the bug mentioned in comment #10.
FreeBSD 9's clang (version 3.0 (branches/release_30 142614) 20111021) is useable,
but I don't have FreeBSD-CURRENT to test.

minux · 2013-02-23T12:57:17Z

Comment 15:

great! I will export CC=/usr/bin/clang in my .bashrc on Mac, it's faster.
btw, according to
http://code.google.com/p/go/source/browse/misc/dashboard/builder/main.go#31
it seems $CC is already passed to child, so maybe you can switch your darwin builder
now (please add a note to go-wiki DashboardBuilder page if you do so)?
all.bash now also pass on FreeBSD 9 release with CC=clang.

davecheney · 2013-02-23T12:58:31Z

Comment 16:

I have tested with whatever clang comes with Lion
% xcodebuild -version
Xcode 4.6
Build version 4H127

bradfitz · 2013-03-11T23:14:45Z

Comment 17:

Why is this a Go1.1 issue?  I ask because a) it's still marked Triage, and b) it doesn't
seem like a show-stopper.

rsc · 2013-03-12T03:17:25Z

Comment 18:

It's a Go1.1 issue because it came in when everything was marked Go1.1 by default, and
it never got triaged. Not anymore. :-)
In general, we are not going to support clang in Go 1.1. I am having a hard enough time
supporting gcc with all the linker changes. Clang will have to wait.

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

davecheney · 2013-06-15T12:37:18Z

Comment 19:

This is still a problem at tip, but the std library now compiles happily
# ../doc/progs
# command-line-arguments
could not determine kind of name for C.stdout
lucky(~/go/src) % hg id
2879112bff3d+ tip
lucky(~/go/src) % $CC -v
Ubuntu clang version 3.2-1~exp9ubuntu1 (tags/RELEASE_32/final) (based on LLVM 3.2)
Target: x86_64-pc-linux-gnu
Thread model: posix

gopherbot · 2013-08-01T02:07:07Z

Comment 20 by kballard:

clang that ships with the current developer seed of Xcode hits the issue mentioned in
comment #10.

gopherbot · 2013-08-01T02:09:25Z

Comment 21 by kballard:

Also worth mentioning that, with the same developer seed of Xcode, there is no GCC
anymore. `gcc --version` prints
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.1.70) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
Due to this, clang build support is required to build Go on OS X with the developer seed
of Xcode.

gopherbot · 2013-09-16T19:45:45Z

Comment 22 by Bailey.D.R:

Is there any update on this? Apple no longer ships with a version of GCC; realistically,
supporting darwin implies supporting clang.

rsc · 2013-09-16T19:51:06Z

Comment 23:

In general, we believe this is fixed: Go uses clang by default on recent OS X and is
working fine. If you know of specific cases that don't work please file new bugs.

Status changed to Fixed.

gopherbot · 2013-09-23T15:06:05Z

Comment 24 by sudhir.j:

Try running go get github.com/gographics/imagick/imagick on OS X 10.8.5 with XCode
Version 5.0 (5A1413). 
Fails with the error 
clang: error: argument unused during compilation: '-fno-eliminate-unused-debug-types'

ianlancetaylor · 2013-09-23T16:09:35Z

Comment 25:

sudhir.j: which version of Go are you using?

flyingmutant · 2013-09-26T21:56:12Z

Comment 26:

Go 1.1.2, OS X 10.8.5, XCode 5.0 (Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM
3.3svn))
# go get github.com/mattn/go-sqlite3
clang: error: argument unused during compilation: '-fno-eliminate-unused-debug-types'
Is this the same bug, a separate bug, or do I have not recent enough version of Go?

ianlancetaylor · 2013-09-26T22:22:44Z

Comment 27:

We believe this bug is fixed on tip and in the 1.2 release candidate.  It is not fixed
in the 1.1.2 release.

gopherbot · 2013-10-08T03:07:37Z

Comment 28 by prencher:

This still appears to be happening, with go1.2rc1 (darwin-amd64-osx10.6) and Xcode 5.0:
$ go get bazil.org/fuse
# bazil.org/fuse
clang: error: argument unused during compilation: '-fno-eliminate-unused-debug-types'
$ go version
go version devel +f4d1cb8d9a91 Thu Sep 19 22:34:33 2013 +1000 darwin/amd64
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
$ clang --version
Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

ianlancetaylor · 2013-10-08T03:36:26Z

Comment 29:

Per comment #23, please file a new bug.  Thanks for reporting this problem.

ianlancetaylor · 2013-10-08T03:37:29Z

Comment 30:

Ah, I see that you did file issue #6544.  Thanks.

athom · 2013-11-20T10:05:23Z

Comment 31:

still suffering this bug.
➜  ~  go version
go version go1.2rc5 darwin/amd64
➜  ~  clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
➜  ~  gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
➜  ~  go get bazil.org/fuse
# bazil.org/fuse
clang: error: argument unused during compilation: '-fno-eliminate-unused-debug-types'
➜  ~

ianlancetaylor · 2013-11-20T14:14:46Z

Comment 32:

Please don't reply on a closed issue.  Please open a new one.  Thanks.
I'm pretty sure that what you are describing is impossible with go1.2rc5.  Please
triple-check that your GOROOT environment variable is either unset or is set correctly.

athom · 2013-11-22T05:31:43Z

Comment 33:

Hi, sorry. You are right. 
It's fixed in  go1.2rc5 now. 
I forgot to update the terminal:p

davecheney · 2013-11-22T05:37:16Z

Comment 34:

I am removing comment permissions for this issue.
If you are experiencing this issue, please check that your XCode compiler is properly
installed and the CLI components are installed. Your compiler should report
$ clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
Iff you are still experiencing problems building Go from source, please open a new issue.

Labels changed: added restrict-addissuecomment-commit.

davecheney added fixed labels Nov 22, 2013

golang locked and limited conversation to collaborators Dec 8, 2014

gopherbot added the FrozenDueToAge label Jun 24, 2016

This issue was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/cgo: cannot use clang 3.2 to compile cgo packages #4829

cmd/cgo: cannot use clang 3.2 to compile cgo packages #4829

davecheney commented Feb 17, 2013

mewmew commented Feb 17, 2013

minux commented Feb 17, 2013

minux commented Feb 17, 2013

minux commented Feb 17, 2013

ianlancetaylor commented Feb 17, 2013

minux commented Feb 19, 2013

minux commented Feb 19, 2013

ianlancetaylor commented Feb 20, 2013

mewmew commented Feb 20, 2013

minux commented Feb 23, 2013

minux commented Feb 23, 2013

davecheney commented Feb 23, 2013

davecheney commented Feb 23, 2013

minux commented Feb 23, 2013

minux commented Feb 23, 2013

davecheney commented Feb 23, 2013

bradfitz commented Mar 11, 2013

rsc commented Mar 12, 2013

davecheney commented Jun 15, 2013

gopherbot commented Aug 1, 2013

gopherbot commented Aug 1, 2013

gopherbot commented Sep 16, 2013

rsc commented Sep 16, 2013

gopherbot commented Sep 23, 2013

ianlancetaylor commented Sep 23, 2013

flyingmutant commented Sep 26, 2013

ianlancetaylor commented Sep 26, 2013

gopherbot commented Oct 8, 2013

ianlancetaylor commented Oct 8, 2013

ianlancetaylor commented Oct 8, 2013

athom commented Nov 20, 2013

ianlancetaylor commented Nov 20, 2013

athom commented Nov 22, 2013

davecheney commented Nov 22, 2013

cmd/cgo: cannot use clang 3.2 to compile cgo packages #4829

cmd/cgo: cannot use clang 3.2 to compile cgo packages #4829

Comments

davecheney commented Feb 17, 2013

mewmew commented Feb 17, 2013

minux commented Feb 17, 2013

minux commented Feb 17, 2013

minux commented Feb 17, 2013

ianlancetaylor commented Feb 17, 2013

minux commented Feb 19, 2013

minux commented Feb 19, 2013

ianlancetaylor commented Feb 20, 2013

mewmew commented Feb 20, 2013

minux commented Feb 23, 2013

minux commented Feb 23, 2013

davecheney commented Feb 23, 2013

davecheney commented Feb 23, 2013

minux commented Feb 23, 2013

minux commented Feb 23, 2013

davecheney commented Feb 23, 2013

bradfitz commented Mar 11, 2013

rsc commented Mar 12, 2013

davecheney commented Jun 15, 2013

gopherbot commented Aug 1, 2013

gopherbot commented Aug 1, 2013

gopherbot commented Sep 16, 2013

rsc commented Sep 16, 2013

gopherbot commented Sep 23, 2013

ianlancetaylor commented Sep 23, 2013

flyingmutant commented Sep 26, 2013

ianlancetaylor commented Sep 26, 2013

gopherbot commented Oct 8, 2013

ianlancetaylor commented Oct 8, 2013

ianlancetaylor commented Oct 8, 2013

athom commented Nov 20, 2013

ianlancetaylor commented Nov 20, 2013

athom commented Nov 22, 2013

davecheney commented Nov 22, 2013