Comment 1:

the ZeroMQ wrapper might be a good test case. Discussion:
https://groups.google.com/d/topic/golang-nuts/st0tegAes4Q/discussion

Comment 2:

I'm bisecting the repo with the llgo build mentioned in that thread.

Comment 3:

A self-contained test case would be really helpful.  From the description this shouldn't
be too hard.

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

Comment 4:

This demonstrates the problem.
On Linux:
Download and install ZeroMQ version 3 from: http://www.zeromq.org/intro:get-the-software
Then, run these commands:
    go get github.com/pebbe/zmq3
    cd $GOPATH/src/github.com/pebbe/zmq3/examples
    go build version.go     # this will fail
But:
    go build -ldflags="-linkmode internal" version.go   # this will succeed
If you already have ZeroMQ version2 installed, and don't want to install version 3, than
you can use this package:
    github.com/pebbe/zmq2

Comment 5:

The error was introduced in 030625a923ca
Not sure if I can produce a reduced testcase, I just encountered this when trying to
build llgo.

Comment 6:

I'm surprised that is the revision that introduces the failure.
Can you attach the error messages to this issue?

Comment 7:

They all look like what I reported in this thread:
https://groups.google.com/forum/m/#!topic/llgo-dev/Efhcn94mwNU
On Friday, April 5, 2013, wrote:

Comment 8:

please run go build with the -ldflags -v option on addition to -x and other options, and
post the exact verbatim output.

Comment 9:

Same as issue #5205?

Comment 10:

Here's the full log generated with, running with the revision in question:
export CGO_LDFLAGS="-L/usr/lib/llvm-3.3/lib -lpthread -lffi -lrt -ldl -lm
-Wl,-L/usr/lib/llvm-3.3/lib -lLLVM-3.3"
export CGO_CFLAGS="-I/usr/lib/llvm-3.3/include -DNDEBUG -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -g -O2
-fomit-frame-pointer -fPIC"
go get -ldflags -v github.com/axw/llgo

Attachments:

1. llgo.log (120842 bytes)

Comment 11:

Status changed to Accepted.

Comment 12:

I applied https://golang.org/cl/8465043 and it appears to have fixed the issue

Comment 13:

Appearances are deceiving. The issue remains.

Comment 14:

I think Kamil is referring to the llgo issue. It's different to this issue. Sorry, I
mentioned this in issue #5205, but not here.

Comment 15:

Seems that the cgo command has a problem with the platform filter between #cgo and
pkg-filter (e.g. #cgo !windows pkg-config).

Comment 16:

Specifically, the problem is that it doesn't recognise the bang. To be fair, the
description at http://golang.org/cmd/cgo/ does not permit this.
Internal linkmode works quite differently: cmd/go parses the pkg-config line, and
interprets the platform filter using standard go/build tag matching (which allows bangs,
multiple tags, etc.); cmd/go then links the cgo library, and calls "cgo -dynimport" to
determine the required shared object names.
A simple (I think?) fix would be to update CGO_LDFLAGS when calling cmd/cgo from cmd/go,
and just remove the pkg-config parsing code from cmd/cgo altogether. I don't know if
there are any good reasons to not do this - someone on the core dev team care to comment?

Comment 17:

I think it would be fine to have the go tool do all the pkg-config parsing.

Comment 18:

Peter: I've just submitted a CL for review, 8610044. I have verified against zmq2. If
you could clpatch and verify against zmq3, that'd be handy.

Comment 19:

Tested with zmq3. It's working.

Comment 20:

This issue was closed by revision d06be39.

Status changed to Fixed.