runtime: can't call from Go to c-shared Go library on Darwin #38692
Comments
|
Can you share the program? |
Please, help me |
Use the |
Then run the program: Can it help you? |
|
There are things I do not understand, my code runs well in ubuntu but not in macos, what's the difference here? |
|
Well that looks like a completely different panic trace.
I do not know. Without a way for us to reproduce it's going to be hard to find out. |
I have uploaded it to the driver, Can you give me your gmail? |
You can send it directly to @randall77 via email. |
|
Marking as release-blocker until we figure out what’s going on. |
How do I solve this problem? Please |
|
We don't know what the problem is. We will most likely need the ability to reproduce this problem ourselves. |
I have uploaded it to the driver, You can see it here |
|
I downloaded your code and tried to run it, but ran into problems. We need exact instructions on how to get to the error posted. Show us every command you issued. |
Thank you for watching, to resolve this error for macos
brew install pkg-config
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/System/Library/Frameworks/Python.framework/Versions/2.7/lib/pkgconfig |
go build -o hybrid_go.so -buildmode=c-shared hybrid_go.go
go run main.go
cd test/ && \
go run main.go |
|
Ok, I can reproduce the problem. Not sure what is going on yet. One thing to try would be to move the python initialization code out of an |
I have tried all possible cases. But does not solve this problem on mac. Everything at Ubuntu is still very good |
|
After finding a lot of ways, the only possible way is to work as sleel in python. You can see it below But it's slow :)) |
|
I got completely different stack trace with this demo program. Click to see stack trace |
I changed the code a bit to reproduce the error, but my problem didn't change |
|
Here's a simple reproducer. foo.go: main.go: This prints Something is wrong with the Go->C->Go path. When we get back to Go, we have an uninitialized environment. |
|
It would be nice if this worked but I'm not terribly surprised that it doesn't. |
ianlancetaylor
changed the title
Will my problem not be solved? |
|
cc @odeke-em @eliasnaur for ideas on a solution. |
|
@khaitranvan96kt I hope that someone will solve your problem. But it is hard in the general case, and I do not know of anybody working on it. Sorry. |
thanks you |
|
@ianlancetaylor Any insight into what it might take to fix (or work around) the darwin symbol collision issue? I'm certainly not an expert in this area, but I'm not finding any solid resources on the darwin-specific dlopen behavior. Perhaps it's related to this "two-level namespace" concept I keep seeing. If you have any pointers, I can dig into it a bit further. |
|
I'm sorry, I don't have any useful pointers. I'm not familiar with the details of shared libraries on macOS. I want to clarify that this is not an intended use case. The That said, I would not be surprised if those options also have trouble on macOS. My point in mentioning this is that if you want to work on fixing something here, I encourage you to focus on |
|
@ianlancetaylor Thanks for the clarification Your doc on the different buildmodes was very helpful. If I'm understanding them properly, I was inspired by the power of As an example, I created a project to make writing Bash plugins easier by abstracting away the C-specific APIs and loading other programs as Based on your last point, focusing more on improving |
That relies on a particular semantics for symbols that occur in both the executable and the shared library, or that occur in multiple shared libraries. ELF provides fairly tight control for how to handle multiple symbol definitions, and Go tries to take advantage of that on ELF systems. But I don't know how that works on macOS. I think it would be useful to remove the requirement that buildmode=plugin and buildmode=shared use exactly the same Go version. But I don't see any plausible way to do it. I guess it might be slightly easier to tackle for plugins, but it would require inventing a completely new mechanism for plugins, and not using the system dynamic linker at all. But we are talking about months of work. |
|
I see, thank you for your responses. Maybe if someone has some intimate knowledge of the macOS dynamic library situation they can chime in. (I may poke around in my spare time, who knows. Based on the source of |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
I wrote a program that combines golang vs python. I call from golang to python and from python call to golang. It works great in Ubuntu but can't work in macos.
Then run the program in macOS Catalina v10.15.3:
What did you expect to see?
Program successfully
What did you see instead?
Program panic
The text was updated successfully, but these errors were encountered: