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.

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

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

Closed
davecheney opened this issue Feb 17, 2013 · 34 comments

Comments

@davecheney
Copy link
Contributor

commented Feb 17, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2013

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

This comment has been minimized.

Copy link
Member

commented Feb 17, 2013

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

This comment has been minimized.

Copy link
Member

commented Feb 17, 2013

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

This comment has been minimized.

Copy link
Member

commented Feb 17, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2013

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

This comment has been minimized.

Copy link
Member

commented Feb 19, 2013

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

This comment has been minimized.

Copy link
Member

commented Feb 19, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2013

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

This comment has been minimized.

Copy link
Member

commented Feb 23, 2013

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

This comment has been minimized.

Copy link
Member

commented Feb 23, 2013

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 23, 2013

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 23, 2013

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

This comment has been minimized.

Copy link
Member

commented Feb 23, 2013

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

This comment has been minimized.

Copy link
Member

commented Feb 23, 2013

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 23, 2013

Comment 16:

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

This comment has been minimized.

Copy link
Member

commented Mar 11, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2013

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

This comment has been minimized.

Copy link
Contributor Author

commented Jun 15, 2013

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

This comment has been minimized.

Copy link

commented Aug 1, 2013

Comment 20 by kballard:

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

This comment has been minimized.

Copy link

commented Aug 1, 2013

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

This comment has been minimized.

Copy link

commented Sep 16, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2013

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

This comment has been minimized.

Copy link

commented Sep 23, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2013

Comment 25:

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

This comment has been minimized.

Copy link

commented Sep 26, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2013

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

This comment has been minimized.

Copy link

commented Oct 8, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2013

Comment 29:

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

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2013

Comment 30:

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

This comment has been minimized.

Copy link

commented Nov 20, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2013

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

This comment has been minimized.

Copy link

commented Nov 22, 2013

Comment 33:

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2013

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.

@golang golang locked and limited conversation to collaborators Dec 8, 2014

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
9 participants
You can’t perform that action at this time.