@mflatt Any idea what I’m missing here? ^
Namely, it looks like ffi-lib is not searching where get-lib-search-dirs says it will, despite what the docs says?
You’re definitely using a 32/64-bit DLL with a 32/64-bit Racket?
55 vs 57?
Woops, wrong image
@sergej I get the same issue with 57.
Does the DLL have any dependencies?
I get this issue with both 32 and 64 bit varients of windows.
I downloaded them from the ffmpeg website. So honestly, I don’t know if they have any deps.
I can check.
Hmm…the website lets you pick. And I’m pretty sure I picked the right one. I’ll see if there is anyway to tell on Windows.
I recommend “depends.exe”
Specifically 3.3.2 > 32/64 (in this case 32) > Shared
Oh cool, thanks.
Hmm…that very likely could be the problem:
They look like standard libraries, but apparently they’re not there.
I think those are VC++ redistributable DLLs, which means that they don’t come with the OS, but applications can redistribute and install them. They’re a pain.
OH
Yup, that’s what I just found out too. (Although its not clear what version of the packages they are).
Anyway…ugg…thanks.
Also keep in mind that just putting the dependencies in Racket’s “lib” won’t make them found. The strategy that works best is to manually load every dependency before anything that needs it.
Welp…ugg… I see.
Would you happen to have a good tutorial on the proper use of them?
(I’m going to assume no, but its worth asking anyway. :slightly_smiling_face: )
@mflatt Oh interesting, it looks like the library was compiled on Ubuntu with the MinGW-w64 toolchain.
I have managed to avoid all VC redistributables – mostly by using MinGW-w64, but maybe there are modes that involve them even with MinGW-w64
So, other than avoiding them, I don’t have good advice for dealing with redistributables
Ha, fair, thanks.
Interesting. I am not finding a mode where mingw-w64 uses VC++ libraries. I wonder if one of the DLLs that build used linked to those libraries.
Oh, here’s a thought. Maybe GCC has its own runtime that tries to mimic the VC++ one.
@mflatt Hmm…apparently this post seems to indeicate that this might not be the case: https://www.windowsforum.org/topic/51273-mingw-c11-app-compiles-cant-run-outside-ide-0xc000007b/
Err…that dependency walker is misleading here.
Ok – now I understand the part of the screen shown by your image. For this purpose, you should pay attention only to the top-left panel of “depends.exe”
But wasn’t that screenshot from the top panel?
Like, here is the whole window.
Ah, okay, I see what you mean now
(I needed a reboot apparently)
@mflatt Ya, it doesn’t seem to have any extra libs.
(AVUtil and SWResample are also part of ffmpeg and in the same directory as AVcocec)
So, does it work to explicitly load “AVUTIL–55.DLL” and “SWRESAMPLE–2.DLL” first?
(since they won’t be found by just being in “lib”)
Oh yes they are.
err…yes it does work.
Odd. I wonder why that worked on OS X. :confused:
(I used the @loader_path symbol when compiling it for os x, that might be why.)
Anyway, thanks. :smile:
Yes, @loader_path avoids the problem
Anyway, this seems to work, if I just reorder the way I load the libraries. Thanks. :slightly_smiling_face:
So, question I should probably know the answer to; does this mean that if I have some lib a.so, that links to b.so (but the link has an absolute path), if the program dynamically loads b.so first, and then a.so, it doesn’t matter what directories the two libraries are in?
@leif Possibly. Probably it depends on the OS, and it may depend on whether the shared library is opened in “global” mode versus “local” mode (where racket uses the latter by default, at least on most platforms)
That makes sense.
Well at least it seems to work on Windows. So thanks. :slightly_smiling_face:
@leif If you haven’t seen it already: https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf
@soegaard2 Oh cool, thanks.