cmd/cgo: C.malloc expects ulong on OS X 10.9 (Mavericks) #5926
Labels
Milestone
Comments
|
Comment 2 by mazdak@chango.com: OS X Mavericks does not ship with gcc or llvm-gcc. Clang is the only option. |
|
Comment 4 by mazdak@chango.com: Well, yes. Xcode 5 does not have GCC. It simply is an alias for clang. I believe they previously deprecated GCC and llvm-GCC and now completely removed them. Clang no longer supports the fno-eliminate-unused-debug-types flag which breaks everything even further. |
It gets further with CC=clang, but doesn't complete. Also: Xcode 5 drops a tool called gcc, but it looks like it's really clang: % gcc -v Configured with: --prefix=/Volumes/Data/Users/ken/Applications/Xcode5-DP3.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.1.65) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix The gcc binary isn't a symlink, it's its own thing. Anyway. % ./all.bash # Building C bootstrap tool. cmd/dist # Building compilers and Go bootstrap tool for host, darwin/amd64. lib9 libbio libmach misc/pprof cmd/addr2line cmd/cov cmd/nm cmd/objdump cmd/pack cmd/prof cmd/cc cmd/gc cmd/6l cmd/6a cmd/6c cmd/6g pkg/runtime pkg/errors pkg/sync/atomic pkg/sync pkg/io pkg/unicode pkg/unicode/utf8 pkg/unicode/utf16 pkg/bytes pkg/math pkg/strings pkg/strconv pkg/bufio pkg/sort pkg/container/heap pkg/encoding/base64 pkg/syscall pkg/time pkg/os pkg/reflect pkg/fmt pkg/encoding/json pkg/flag pkg/path/filepath pkg/path pkg/io/ioutil pkg/log pkg/regexp/syntax pkg/regexp pkg/go/token pkg/go/scanner pkg/go/ast pkg/go/parser pkg/os/exec pkg/os/signal pkg/net/url pkg/text/template/parse pkg/text/template pkg/go/doc pkg/go/build cmd/go # Building packages and commands for darwin/amd64. runtime errors sync/atomic unicode unicode/utf8 math sort unicode/utf16 crypto/subtle container/list container/ring sync image/color runtime/race container/heap io syscall hash crypto/cipher crypto hash/crc32 crypto/hmac hash/adler32 hash/crc64 hash/fnv crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512 bytes strings time path bufio text/tabwriter html compress/bzip2 strconv math/rand math/cmplx os reflect regexp/syntax net/url encoding/base64 crypto/aes crypto/rc4 encoding/ascii85 encoding/base32 image encoding/pem path/filepath os/exec os/signal io/ioutil image/draw image/jpeg regexp fmt encoding/binary debug/dwarf crypto/des index/suffixarray flag go/token text/template/parse log debug/elf debug/macho debug/pe encoding/json go/scanner encoding/xml compress/flate math/big encoding/hex go/ast mime encoding/gob runtime/pprof text/template compress/gzip archive/zip text/scanner cmd/yacc crypto/elliptic crypto/rand crypto/dsa encoding/asn1 crypto/rsa crypto/ecdsa archive/tar html/template go/doc go/parser go/printer compress/lzw compress/zlib crypto/x509/pkix database/sql/driver debug/gosym encoding/csv database/sql image/gif image/png runtime/debug go/build testing testing/iotest cmd/cgo go/format cmd/gofmt testing/quick cmd/fix cmd/api cmd/vet runtime/cgo net os/user # os/user lookup_unix.go:64: cannot use _Ctype_size_t(bufSize) (type C.size_t) as type C.ulong in function argument crypto/x509 net/textproto log/syslog mime/multipart net/mail crypto/tls net/http net/smtp cmd/go expvar net/http/pprof net/http/cgi net/http/cookiejar net/http/httptest net/http/httputil net/rpc cmd/godoc net/http/fcgi net/rpc/jsonrpc |
issue #5822 is tracking the switch to invoking clang on OS X. The remaining issue here is the C.malloc prototype not working right. It looks like someone changed the definition of malloc on OS X 10.9 from taking size_t to ulong (C doesn't care, if they typedef to the same thing, but Go does). |
|
Comment 9 by mazdak@chango.com: I am able to build with the changes above; however, I am getting this error: # command-line-arguments xxxx.go:190:12: struct size calculation error off=40 bytesize=32 The same go file (which is actually a cgo file) works on older versions of OS X and Linux. |
|
Comment 10 by mazdak@chango.com: To assist, here is a snippet that reproduces the above problem:
package main
/*
#include <stdlib.h>
enum ct { A = 0x00, B = 0x01};
typedef enum ct ct;
typedef struct cobject_s {
enum ct type;
size_t sz;
union {
char *str; // note for str: sz is strlen (not strlen+1
void *blob;
int64_t i64; // easiest to have one large int type
} u;
void *free; // if this is set, this must be freed on destructuion
} cobject;
typedef struct cbin_s {
char bin_name[32];
cobject object;
} cbin;
*/
import "C"
func main() {
var a C.cbin
}
|
The prototype for malloc still looks like it wants size_t in the 10.9 headers. Could something else be keeping go from picking it up correctly? /Volumes/Data/Users/ken/Applications/Xcode5-DP3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/stdlib.h: void *malloc(size_t); /Volumes/Data/Users/ken/Applications/Xcode5-DP3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/5.0/include/stddef.h: #if !defined(_SIZE_T) || __has_feature(modules) /* Always define size_t when modules are available. */ #if !__has_feature(modules) #define _SIZE_T #endif typedef __SIZE_TYPE__ size_t; #endif ken@Nepheli ~> clang -dM -E - < /dev/null | grep SIZE_TYPE #define __SIZE_TYPE__ long unsigned int |
Re "size calculation error", probably the padding rules are different somehow. Re size_t vs ulong, my guess is that the clang DWARF output is not mentioning size_t but instead saying unsigned long as the type of the argument to malloc. Clang support for generating DWARF information has been problematic and is really only barely passable. |
I'm running into this not even trying to build Go; I'm just installing the websockets package and I get the same error: gcc -I . -g -O2 -fPIC -m64 -pthread -fno-common -o $WORK/runtime/cgo/_obj/_all.o $WORK/runtime/cgo/_obj/_cgo_export.o $WORK/runtime/cgo/_obj/cgo.cgo2.o $WORK/runtime/cgo/_obj/gcc_darwin_amd64.o $WORK/runtime/cgo/_obj/gcc_setenv.o $WORK/runtime/cgo/_obj/gcc_util.o $WORK/runtime/cgo/_obj/gcc_amd64.o -Wl,-r -nostdlib libgcc.a # runtime/cgo clang: error: no such file or directory: 'libgcc.a' Xcode 5 is about to ship, assuming it has the same release schedule (9/17) that iOS 7 does. Sounds like a whole lot of Mac-based developers are going to run into this bug then, since Software Update likes to semi-automatically upgrade stuff... |
one more data point. attached is CGO_ENABLED=0 compilation with xcode 5.0. all tests pass. Attachments:
|
Chiming in with my own datapoint: - Ubuntu 12.04 (precise) 32-bit (vagrant's precise32.box running in VirtualBox) - Binary Clang+LLVM 3.3 from llvm.org (debian 6 package, because no 32-bit ubuntu one) - Latest tip - CC=clang Fails exactly the same as #6: pkg/os/user/lookup_unix.go:64: cannot use _Ctype_size_t(bufSize) (type C.size_t) as type C.uint in function argument Looks like this is a clang-3.3 issue, not just a OSX-Mavericks one. |
As clang 3.3 and OS X 10.9 are likely to land before, or soon after 1.2 ships I think the priority if this issue should be raised. I've marked it as such, please feel free to revert this change if it is not appropriate. Labels changed: added priority-later, go1.2, removed priority-accepted, go1.2maybe. |
|
This issue was closed by revision 397ba2c. Status changed to Fixed. |
all.bash on mavericks on a fresh clone of the repo past revision 46fd4ef6c0de Attachments:
|
|
Comment 25 by mazdak@chango.com: Any reason why the following snippet doesn't work?
Error:
# command-line-arguments
xxxx.go:190:12: struct size calculation error off=40 bytesize=32
-----
package main
/*
#include <stdlib.h>
enum ct { A = 0x00, B = 0x01};
typedef enum ct ct;
typedef struct cobject_s {
enum ct type;
size_t sz;
union {
char *str; // note for str: sz is strlen (not strlen+1
void *blob;
int64_t i64; // easiest to have one large int type
} u;
void *free; // if this is set, this must be freed on destructuion
} cobject;
typedef struct cbin_s {
char bin_name[32];
cobject object;
} cbin;
*/
import "C"
func main() {
var a C.cbin
}
|
|
Comment 27 by mazdak@chango.com: Done. Thank you. New issue: https://golang.org/issue/6368 |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by mazdak@chango.com:
The text was updated successfully, but these errors were encountered: