I've been trying to debug this for a while, unsuccesfully: dlopen'ing and running a function out of a @rustlang *binary* instead of a cdylib mostly works, but makes thread related code segfault: https://github.com/m-ou-se/rust-lib-and-binary-testcase … Any ideas? I'm really curious what's happening here.
-
Show this thread
-
Maybe a mismatch in libc versions. I guess compiling a dynamic library with Rust, relays on libc located in your C executable. When compiling an exe, it links against a static version of libc. If it mismatches the version your C program has, it will result with a core dump.
1 reply 0 retweets 0 likes -
This is just an educated guess. Sadly I lack the time to debug it, and I haven't got the chance to do this kind of debugging with Rust. But had enough of it with C++, so I'm kinda confident with my guess. Try to see if it crashes when jumping to a libc function if you can
1 reply 0 retweets 0 likes -
Replying to @oribenshir @rustlang
Both link libc dynamically:pic.twitter.com/gVEp5VxNMp
1 reply 0 retweets 0 likes -
Other using libc functions (creating a file for example) work fine.
1 reply 0 retweets 0 likes -
So that doesn't seem like it either. :( The search continues!
1 reply 0 retweets 0 likes -
Darn, I thought it was a good direction, and I've heard Rust compiles all libraries statically, but haven't really tested it before. I'll try to think about other approaches tomorrow.
1 reply 0 retweets 1 like
Rust compiles *rust code* statically But dynamically links libc by default
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.