[go-nuts] Re: Why go plugin addresses do not load with go binary #49225

Thanks. On Monday, November 1, 2021 at 8:56:38 PM UTC+5:30 Brian Candler wrote: > On Monday, 1 November 2021 at 13:44:28 UTC chauhan...@gmail.com wrote: > >> greeter.go calls plugin.open and it will be work only for one sub version >> of go. If plugin and binary are made in different sub versio

Re: [go-nuts] How to force cgo to use C++ compiler (g++) instead of gcc ?

On Sun, Oct 31, 2021 at 10:17 AM Elemer Pixard wrote: > > I am developing a binding to a C++ library > using a wrapper module (using extern "C" directive). > The C++ library files are in a subdirectory of the package. > > If I create a file in the package directory such as: > > lib.cpp > -

Re: [go-nuts] How does the garbage collector determine that an object is reachable?

On Mon, Nov 1, 2021 at 9:30 AM Shanshan He wrote: > > Hello, I'm reading the GC code recently, but I didn't find any code about > analyzing whether an object is reachable or not (or say whether a pointer is > live), can someone give me some hints? > > I see that each heap word corresponds to a h

[go-nuts] Average of two strings

Hi, I wrote MeanStr(s1,s2) to calculate lexicographic average of two strings. It works fine with ascii strings but I want to get feedback on general (utf-8) inputs. It should satisfy: - a good average of two inputs (in some context): For mos

[go-nuts] Unable to create Api | Go Operator | Go issue

Hello Team getting below error while using below command could you please help us what can be done to resolve this issue ? root@k8sopa1:~/projects/memcached-operator# operator-sdk create api --group cache --version v1alpha1 --kind Memcached --resource --controller Writing kustomize manifests fo

[go-nuts] Re: How to force cgo to use C++ compiler (g++) instead of gcc ?

Hmm, previous suggestion to use '#cgo CFLAGS: -x c++' doesn't seem to work all the way. [I've only tested class declarations at the time.] Trouble is that '-x c++' is passed even when compiling the glue code, so that even glue symbols get decorated, which doesn't fly with linker at the end. I s

[go-nuts] How does the garbage collector determine that an object is reachable?

Hello, I'm reading the GC code recently, but I didn't find any code about analyzing whether an object is reachable or not (or say whether a pointer is live), can someone give me some hints? I see that each heap word corresponds to a heapBits. By doing & operation with bitscan and bitPointer we

[go-nuts] Re: How to force cgo to use C++ compiler (g++) instead of gcc ?

> lib.go > -- > package lib > > // #cgo CFLAGS: -x c++ > // #include "cpplib/file.cpp" > // #include "cpplib/wrapper.cpp" > import "C" > Formally, the remaining question is if C compilers on all of your target platforms support -x option. In the worst case, if some does not, you

[go-nuts] Re: Why go plugin addresses do not load with go binary #49225

On Monday, 1 November 2021 at 13:44:28 UTC chauhan...@gmail.com wrote: > greeter.go calls plugin.open and it will be work only for one sub version > of go. If plugin and binary are made in different sub versions of go1.15 > then plugin.open will not work. > > That is correct, that is how it is

Re: [go-nuts] Re: Why go plugin addresses do not load with go binary #49225

On Mon, Nov 1, 2021 at 9:44 AM Manoj Chauhan wrote: > Hi Brian, > > greeter.go calls plugin.open and it will be work only for one sub version > of go. If plugin and binary are made in different sub versions of go1.15 > then plugin.open will not work. > It sounds like you want to ignore a major wa

[go-nuts] Re: Why go plugin addresses do not load with go binary #49225

Hi Brian, greeter.go calls plugin.open and it will be work only for one sub version of go. If plugin and binary are made in different sub versions of go1.15 then plugin.open will not work. On Monday, November 1, 2021 at 6:55:02 PM UTC+5:30 Brian Candler wrote: > > My question was how to load

[go-nuts] Re: Why go plugin addresses do not load with go binary #49225

> My question was how to load plugin address in go runtime using LD_PRELOAD. I am using LD_PRELOAD because plug.open is failed. Is there any other solution? When I tried it, I didn't need to set any environment variables (and certainly no LD_XXX variables). Follow this tutorial: https://medium

[go-nuts] Re: Why go plugin addresses do not load with go binary #49225

If eng.so is under /usr/lib then I think it's not required to set LD_LIBRARY_PATH. My question was how to load plugin address in go runtime using LD_PRELOAD. I am using LD_PRELOAD because plug.open is failed. Is there any other solution? On Monday, November 1, 2021 at 1:33:09 PM UTC+5:30 Brian

[go-nuts] Re: Why go plugin addresses do not load with go binary #49225

On Monday, 1 November 2021 at 03:44:03 UTC chauhan...@gmail.com wrote: > I did not understand the use of plugin. I can't use a plugin with > different go versions even with minor version because plugin.open is failed. > That is indeed correct, and is a major limitation of plugins in go. See: ht