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

proposal: cgo: c code can call c function that defined in another cgo package #19746

Closed
bronze1man opened this issue Mar 28, 2017 · 5 comments
Closed

Comments

@bronze1man
Copy link
Contributor

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.7.5 darwin/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH=""
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/m9/qtbxkp6s3p96fk54rln7qhj80000gp/T/go-build255881879=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?

  • define a c function in a .c file in one cgo package of in my project (GOPATH)
  • define the c function prototype again and call that c function in another cgo package in my project.

What did you expect to see?

Compile success.

What did you see instead?

Compile fail.

@bronze1man
Copy link
Contributor Author

bronze1man commented Mar 28, 2017

I managed to implement this feature with go1.7.5 with darwin/ios/linux/android.

I have test that changeset in mac/ios/android os.

Here is the changeset:

diff --git a/src/cmd/go/build.go b/src/cmd/go/build.go
index 3c0b994..f3b9515 100644
--- a/src/cmd/go/build.go
+++ b/src/cmd/go/build.go
@@ -3348,7 +3355,15 @@ func (b *builder) cgo(p *Package, cgoExe, obj string, pcCFLAGS, pcLDFLAGS, cgofi
        if pie { // we need to use -pie for Linux/ARM to get accurate imported sym
                cgoLDFLAGS = append(cgoLDFLAGS, "-pie")
        }
-       if err := b.gccld(p, dynobj, cgoLDFLAGS, linkobj); err != nil {
+       symLDFlAGS := cgoLDFLAGS
+       if goos=="darwin"{
+               // clang
+               symLDFlAGS= append(symLDFlAGS,"-flat_namespace","-Wl,-undefined,warning")
+       }else{
+               // gcc
+               symLDFlAGS= append(symLDFlAGS,"-Wl,--unresolved-symbols=ignore-all")
+       }
+       if err := b.gccld(p, dynobj, symLDFlAGS, linkobj); err != nil {
                return nil, nil, err
        }
        if pie { // but we don't need -pie for normal cgo programs

I do not know how to port this feature to go1.8

@bradfitz
Copy link
Contributor

This seems like a bad idea and breaks backwards compatibility.

Also, We do not accept changes on the issue tracker. Code must only come via https://golang.org/doc/contribute.html

Even if this feature were approved, that code is not gofmt'd and does not have tests. Its detection of clang-vs-gcc is also overly simplistic. In the future, please wait for approval before sending code.

@bradfitz
Copy link
Contributor

I suggest you discuss on the mailing list about your actual problem before jumping to a solution. (See http://xyproblem.info/)

For questions about Go, see https://golang.org/wiki/Questions.

@bronze1man
Copy link
Contributor Author

I add this feature to my own go1.7.5, so that I can write a rpc that can call objective c from golang function/call golang function from objective c in every package without write one line about complex cgo stuff.
Without this feature, I just need every package have same c function implement that marshal stuff.

I do not understand why you guys do not even want to discuss it.

"This seems like a bad idea and breaks backwards compatibility."
This proposal do not break backwards compatibility. Normal golang code can run on this.You just can call bigger range of code.

I looks like I have to port those changs to go1.8 myself. if I want to upgrade to that golang version.
I take a lot of effort to ask your guys to merge this pr.
I think I can just save that time to add more powful feature to my own golang like package

@ianlancetaylor
Copy link
Member

Brad didn't say that we don't want to discuss it, he said that we want to discuss it on a mailing list instead of the issue tracker. Thanks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants