[go-nuts] cgo can't find .so in same directory

Tweak your ld.conf configs and call ldconfig till ldd finds all libs of your binary. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [go-nuts] Store function name as JSON?

On Wed, Apr 29, 2020 at 02:17:44PM -0700, MichaelB wrote: > I'm trying to store a data point as a JSON (w/struct) with a Call back > function to call when the item is loaded with data Functions aren't serializeable to json, it's not one of the types json supports. > Just marshaling the struct

[go-nuts] cgo can't find .so in same directory

I'm following a simple example of using cgo to call a C library function from go. Executing the binary gives error while loading shared libraries: libperson.so: cannot open shared object file: No such file or director Here's

Re: [go-nuts] External/internal linker and cgo packages

On Wed, Apr 29, 2020 at 8:58 PM Vincent Blanchon wrote: > > Thank you again for your reply! > I thought Go would compile all the C files in one .go, that makes sense. > > By the way, how Go would deal with those files if cgo is not enabled - > meaning the internal linker will do the job? > How

Re: [go-nuts] External/internal linker and cgo packages

Hello Ian, Thank you again for your reply! I thought Go would compile all the C files in one .go, that makes sense. By the way, how Go would deal with those files if cgo is not enabled - meaning the internal linker will do the job? How the internal linker can deal with that? Le jeudi 30 avril

Re: [go-nuts] External/internal linker and cgo packages

On Tue, Apr 28, 2020 at 10:49 PM Vincent Blanchon wrote: > > I'm building a simple program that has a dependency to > github.com/DataDog/zstd, a wrapper of a C code. > So by default, Go will use the external linker. When debugging with, I can see > > host link: "clang" "-m64"

[go-nuts] Store function name as JSON?

Hey Gophers, I'm trying to store a data point as a JSON (w/struct) with a Call back function to call when the item is loaded with data Just marshaling the struct into JSON nets a blank item.. any suggestions? example: type Item struct { name string callback func() data int } ... func

Re: [go-nuts] Safe ways to call C with less overhead

On Wed, Apr 29, 2020 at 12:45 PM wrote: > > 1) I have heard gccgo can call C much quicker than the standard go > implementation can. If this statement is true, why is that? It's because gccgo uses the C calling convention. So you can use a magic //go:linkname comment to rename a Go function

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

Aaah ok, so my usage should have been v1.0.0-pre-release.1 and v1.0.0-pre-release.2 ; and indeed, when I've tested it it does work. Thank you On Wednesday, April 29, 2020 at 8:41:39 PM UTC, Sean Liao wrote: > > semver point 10: > > Build metadata MUST be ignored when determining version

Re: [go-nuts] Is this a safe way to block main thread but not main goroutine?

As Thomas said, this will work for sure, though, and doesn't require any manual setup, and you don't need to do funny business with CGO. func main() { go doAllYourOtherStuff() blockOnDarwinEventLoop() } Done. On Wed, Apr 29, 2020 at 1:44 PM Akhil Indurti wrote: > I want to mirror (or

Re: [go-nuts] Is this a safe way to block main thread but not main goroutine?

I want to mirror (or control) the event loop inside the main goroutine. The main goroutine should be the one to block for events. Plus, as long as it's safe, it doesn't seem needlessly complex to me. On Wednesday, April 29, 2020 at 4:38:27 PM UTC-4, Thomas Bushnell, BSG wrote: > > That seems

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

semver point 10: > Build metadata MUST be ignored when determining version precedence. chat log from slack: > 22:29 bcmills Tags with metadata are not unique: there is only a partial order among them, not a total order. > 22:30 In contrast, MVS requires a total order. (We can't choose between

Re: [go-nuts] Is this a safe way to block main thread but not main goroutine?

That seems needlessly complex. Why not just skip the weird init, and just have main do a go to the thing you want to be not on the main thread, and let the main thread do its thing? On Wed, Apr 29, 2020 at 4:19 PM Akhil Indurti wrote: > I want to run the main goroutine on another thread besides

[go-nuts] Is this a safe way to block main thread but not main goroutine?

I want to run the main goroutine on another thread besides the main thread, so that the main thread can block in darwin UI code. Is this a safe way to do it? package main /* #include #include void block() { printf("Blocking main thread? %d\n", pthread_main_np()); while(1); }

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

go does mean semver.org when it refers to semver > Modules must be semantically versioned according to semver[,...] refers to what the numbers mean, the v prefix is required but not part of the version, more clearly explained in a faq on semver.org: > Is “v1.2.3” a semantic version? > No,

[go-nuts] Safe ways to call C with less overhead

I am interested in having less overhead for Go-C-Go roundtrips, for C programs that I know (or at least am very much sure) will behave, for most part, similar to non-preemptible (as in prior to Go 1.14) loops in Go. Concretely, I have a self-imposed exercise of making a frankenprogram that talks

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

On Wednesday, April 29, 2020 at 6:57:55 PM UTC, Uli Kunitz wrote: > > The documentation provided by go help modules doesn't refer to semver.org > and the Backus-Naur-Form there, so you cannot assume it is supported. The > semver.org BNF doesn't support the leading v letter, so Go modules >

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

On Wednesday, April 29, 2020 at 6:57:55 PM UTC, Uli Kunitz wrote: > > The documentation provided by go help modules doesn't refer to semver.org > and the Backus-Naur-Form there, so you cannot assume it is supported. The > semver.org BNF doesn't support the leading v letter, so Go modules >

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

The documentation provided by go help modules doesn't refer to semver.org and the Backus-Naur-Form there, so you cannot assume it is supported. The semver.org BNF doesn't support the leading v letter, so Go modules versions are anyway incompatible. -- You received this message because you are

[go-nuts] Re: Getting pkcs12: unknown attribute with OID 1.3.6.1.4.1.311.17.2 with ToPEM call

Well, FWIW, this still seems to be an issue in 2020 with Go 1.14 On Monday, November 5, 2018 at 6:25:53 AM UTC+1, jyo...@gmail.com wrote: > > Hi > > I'm trying to extract a certificates,keys from the .pfx file using the > call ToPEM. > > I get this error > > pkcs12: unknown attribute with OID

[go-nuts] Possible bug in turning versions into pseudo-versions

Hello, recently I've created a new golang library and released it with pre-release version first to catch any bugs before doing proper 1.0.0 release. The pre-release version was called 1.0.0-pre-release+1 , which according to https://semver.org/ should be completely legal semver. If I read the

Re: [go-nuts] Re: marshal multiple json documents which may have different format versions into the latest struct version

That sounds like a good plan. I'm going to try that. Thank you Manlio! Am Di., 28. Apr. 2020 um 15:11 Uhr schrieb Manlio Perillo < manlio.peri...@gmail.com>: > On Tuesday, April 28, 2020 at 10:52:56 AM UTC+2, Chris Burkert wrote: >> >> Dear all, >> >> my application users shall be able to

[go-nuts] Re: Json Parse Data [unexecpted non whitespace 1 to 28]

You have a specific piece of input data which is causing this error "json data parse after line 1 to 28" Therefore, please modify your code to print the actual value just before parsing it; then do whatever triggers the error; then place that value inside the play.golang.org program to

Re: [go-nuts] Need a way to check only key exist or not? without value?

On Wednesday, 29 April 2020 01:33:55 UTC+1, Shishir Verma wrote: > > I think it is kind of intuitive that empty struct takes 0 bytes > To me it wasn't intuitive, but that's because my brain instinctively read it as "interface {}" and not "struct {}". It's clear that a struct{} must occupy zero

[go-nuts] Re: Json Parse Data [unexecpted non whitespace 1 to 28]

[Unexcepted NonWhitespacing json data parse after line 1 to 28 ] You can checkout my repo https://github.com/ali2210/HealthyTickets/blob/master/main.go On Tuesday, April 28, 2020 at 1:53:38 PM UTC+5, Ali Hassan wrote: > > [image: Capture.JPG] > > Data : TYPE OF Json > > > > var member