New to Rust: How does Rust handle dynamic libraries (programming.dev)

submitted 1 year ago* (last edited 1 year ago) by BehindTheBarrier@programming.dev to c/rust@programming.dev

14 comments fedilink hide all child comments

I'm super new to Rust, like a day old really.

But I tried a program made in Rust on Windows, and it refuses to work.

Never prints anything. Just straight up instantly dead. Long story short, this thing relies on some linked stuff like ffmpeg in some form. So, I did my best trying to gather all the things it needs per github issues, reddit and other souces. And the end result was that it now spent 0.1 s longer before crashing, actually leaving time for some error in the Windows Event log. Nothing useful there either as far as I can see.

So I clone the repo and get the required things to compile Rust, and I managed to build it from source at least. The executable doesn't run, but the Run in VS Code works, somehow. It prints the error messages corresponding to missing input. So i try to debug it, but nothing happens. No breakpoint is hit, and nothing is printed in the terminal, unlike when using Run or cargo Run. I can also just strip out everything it does in the file the main function is in, and it will hit breakpoints. But that didn't help me find out what is missing/broken though.

So what the difference, is there a way to catch and prevent Rust from just going silent, and actually tell you what dependencies it failed to load?

My entire reason for getting it running locally is to fix that. Because no one sane wants to deal with a program that doesn't tell you why it will not run... And when debugging also does nothing... I'm out of ideas.

The program is called Av1an for reference, and it's a video encoding tool. I used a python version before they migrated to Rust, and wanted to give it a try again.

Edit: Wrote linked library, but i think the proper term is dynamic libraries. I'm really not good with compiled programs.

Update: Figured it out. Had to copy the out files from the ffmpeg compiled stuff back to the executable. Apparently Cargo Run includes that location when looing for the files, while running from the command line clearly doesn't.

But the biggest whiplash, was that I got a full windows dialog popup when i tried to in the exectuable in CMD instead of Powershell. Told me the exact file I was missing too. I know PowerShell is a bitch when piping stuff, but I'm amazed no other program or error message could hand me that vital information. Fuck me, I wish I had tried that from the start....

top 14 comments

sorted by: hot top controversial new old

[-] urbeker@programming.dev 9 points 1 year ago

Dynamic libs in rust are supported but only through a c abi and it's a bit complicated.

Looking at av1an I couldn't see anything showing it is dynamicly loading anything, it looks to statically link to ffmpeg according to the build instructions.

[-] BehindTheBarrier@programming.dev 1 points 1 year ago

Thanks you for looking into it, if they are statically linked can something be done about it? Aka, same as other case, how do you detect missing required library to actually throw an error?

The issues where I learned most of it is here: https://github.com/master-of-zen/Av1an/issues/676

Having to build and find a ton of dlls is cumbersome. While I'm fairly sure I'm missing some ffmpeg ones, I'm somewhat taken aback by how running it with cargo run works just fine. But trying to run the very same executable built doesn't. And debugging also doesn't do anything. That doesn't make much sense to me, since the access to said dlls should be the same either way?? Either none of them works, or both does. Or there is some big difference between Cargo Run and the compiled executive when it comes to static or dynamic dlls loading.

[-] urbeker@programming.dev 1 points 1 year ago

OK so looking at that PR the reason you aren't getting any errors is because it looks like one of the dependencies is trying to load python and thats where the error occurs. Rust would normally give you a pretty good stack trace but because this is happening in external code it can't and you won't fix it in the av1an codebase. vscode likely has its path setup differently allowing it to find python. I would double check the paths inside the vscode terminal and wherever you are running it.

[-] BehindTheBarrier@programming.dev 1 points 1 year ago

It's definitely a clue, but I got both system wide python, and a embedded one hooked up to vapoursynth (another dependency). Still doesn't explain why debugger doesn't work but running it does. As far as I see it, they should be the same.

Not sure if there is a solution, but I'm somewhat perplexed that the top level program can't handle crashes for a dependency it is either trying to load or use.

Thanks for the effort however, much appreciated.

[-] SorteKanin@feddit.dk 7 points 1 year ago

What do you mean "the executable doesn't run"? What error messages are you getting? Showing actual code or error message would probably get you more help.

[-] BehindTheBarrier@programming.dev 1 points 1 year ago

I can show you something after work, if I remember to. The gist of my issue is, a compiled executable doesn't give any error at all or anything else. It's because of missing dlls, and I want to find out what and how to prevent it so that the program does tell you why it is not working. If that is even possible.

I can compile the source, and it magically works with cargo run, but otherwise not. Debugging is completely silent, doesn't seem like it even notices the process.

[-] BehindTheBarrier@programming.dev 1 points 1 year ago

Here's how it looks when ran from Powershell:

PS C:\Users\Username\RustProjects\Av1an> cargo run --release -- -i .\test.webm
    Finished release [optimized] target(s) in 0.31s
     Running `target\release\av1an.exe -i .\test.webm`
INFO [av1an_core::context] Input: 2560x1440 @ 60.000 fps, YUV420P, SDR
Scene detection
00:00:02 ▐████████████████████████▒                                                   ▌  32% 226/697 (89.17 fps, eta 5s)
error: process didn't exit successfully: `target\release\av1an.exe -i .\test.webm` (exit code: 0xc000013a, STATUS_CONTROL_C_EXIT)
PS C:\Users\Username\RustProjects\Av1an> .\target\release\av1an.exe -i .\test.webm
PS C:\Users\Username\RustProjects\Av1an> cd .\target\release\
PS C:\Users\Username\RustProjects\Av1an\target\release> .\av1an.exe -i ..\..\test.webm

Running from the very same Powershell window. Take note that there is nothing for the normal lines because it's instant death, not even a split second stutter before powershell is ready for a new command. The cargo run works, so why doesn't a release compiled executable do the same, when it's using the same file? What difference does cargo run make?

[-] SorteKanin@feddit.dk 1 points 1 year ago

Hmm have you tried running in an administrator shell? Just wondering if there's some kind of security thing preventing this.

[-] BehindTheBarrier@programming.dev 1 points 1 year ago

No dice there either...

[-] RunAwayFrog@sh.itjust.works 1 points 1 year ago* (last edited 1 year ago)

If you were on GNU/Linux, my answer to your questions would have had nothing to do with Rust. It would have involved tools like readelf and ldd, maybe strace.

So, maybe check out what equivalent tools exist on Windows, and try using them.