Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

It seems you are right. I'm not sure if my understanding is correct: I guess that this problem occured because gollvm just exposes the interface of exported functions in the lib, so the private function can't be accessed. I want to know if there is any way to make the internal functions of the

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

Than, Appreciate you saying that. And you're very welcome. On Tue, Mar 30, 2021 at 8:29 PM Than McIntosh wrote: > Thank you @Ugorji Nwoke , I appreciate your going > the extra mile to include gollvm in your testing. > > Cheers, Than > > > On Tue, Mar 30, 2021 at 11:17 AM Ugorji Nwoke wrote:

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

Thank you @Ugorji Nwoke , I appreciate your going the extra mile to include gollvm in your testing. Cheers, Than On Tue, Mar 30, 2021 at 11:17 AM Ugorji Nwoke wrote: > Ugorji here - author of the github.com/ugorji/go/codec > package. > > The

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

Ugorji here - author of the github.com/ugorji/go/codec package. The notes below are for folks that are interested in why we use unsafe, and how we mitigate concerns around it. As Peter mentioned above, you can pass the build tag "codec.safe" to

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

> The Go runtime and standard library has a public, exported API; this sort of use of go:linkname to reach into the internals of a standard package (in this case, calling an unexported function) is not supported. The limitation to access private functions in std package sounds reasonable. > You

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

On Monday, March 29, 2021 at 8:32:53 AM UTC-4 peterGo wrote: > You haven't said whether you followed the "safe" instructions for > github.com/ugorji/go/codec to avoid building code/helper_unsafe.go, which > uses go:linkname. > > s/code/helper_unsafe.go/codec/helper_unsafe.go/ Peter -- You

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

You haven't said whether you followed the "safe" instructions for github.com/ugorji/go/codec to avoid building code/helper_unsafe.go, which uses go:linkname. Package Documentation for github.com/ugorji/go/codec https://github.com/ugorji/go/blob/master/codec/README.md This package will

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

Hi, *>Thanks for your attention, but I tried to write a demo with go:linkname.* *>In fact, it works well with gollvm...So maybe it is not the exact cause for the problem* The problem is not that gollvm fails to implement go:linkname-- the problem is the way that this package

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

> go:linkname to refer directly to functions that are defined but not exported by the standard library. > This is not supported and is likely to break with any new release. It evidently breaks with GoLLVM. Thanks for your attention, but I tried to write a demo with go:linkname. In fact, it

Re: [go-nuts] gollvm hasn't a good support to reflect and pthread?

On Sun, Mar 28, 2021 at 9:28 AM 张嘉熙 wrote: > > For s2-geojson, I meet: > ``` > # github.com/pantrif/s2-geojson/cmd/s2-geojson > /home/jx/.cache/go-build/6b/6bd003c99eb0a9e7c6ea6d372307b292ec615c75c28f9b1f696896ae2fb4272b-d(_go_.o):gomodule:function >

[go-nuts] gollvm hasn't a good support to reflect and pthread?

I made a issue at github, and the details are as followed: ### What version of Go are you using (`go version`)? $ go version go version go1.16 gollvm LLVM 13.0.0git linux/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture