Dynamic library usage
-
I've been trying to figure out how to use "FluidSynth":http://sourceforge.net/apps/trac/fluidsynth/, an open source software synthesizer. It's a pain to build it in Windows, so I'm trying to use the DLLs someone else was nice enough to provide on "his personal site":http://fluidsynth.flyx.org/. There are 5 files, four of them for dependencies (I think GTK). I've never worked with DLLs, and I get the impression from the "QLibrary description":http://qt-project.org/doc/qt-4.8/qlibrary.html#details that it's a real chore: Do I correctly understand that every function in a DLL needs to be individually resolved before it can be used? I'm also unclear about whether the DLLs are sufficient -- "an earlier thread":http://qt-project.org/forums/viewthread/6960 suggests that a DLL may require an accompanying LIB file. Is that true, and if not, how does its absence change the process? Lastly, I was hoping someone could set me straight about the role of header files. Since I have the source, I thought it might give me some additional options (is static linking still a possibility?).
-
This explains it: http://msdn.microsoft.com/en-us/library/9yd93633(v=vs.80).aspx
If you link your app you will need the .lib files as well as the DLLs.
-
Thanks, that's a helpful link. I'm still not quite able to make sense of that qt-project thread, but MSDN and "another discussion":http://stackoverflow.com/questions/3250467/what-is-inside-lib-file-of-static-library-statically-linked-dynamic-library-an I found both confirm that there are two ways to link to a DLL. Linking statically requires a .lib file, but allows DLL functions to be used as if they were part of source. A DLL without a .lib file can be dynamically linked, but that requires the function resolution code I was hoping to avoid.
Please chime in if any of this doesn't sound right.
-
Ok, I've made significant strides, but I'm stuck again. I managed to finally create an import library (.a, not .lib since I'm using MinGW), and got my program to compile, only to have it crash instantly "with code -1073741515." I then decided I would have a go at compiling the DLL myself. I managed to do it, but with exactly the same result at run time. I then opened the (new) DLL with Dependency Walker, which told me there were two missing modules, GPSVC.dll and IESHIMS.dll. Judging from other posts, these would appear to be false positives (I'm certain both of these files are present), so I currently see no way forward. I'd appreciate any recommendations.
-
Hi planarian,
if you run in srashes, you should use the debugger. from just: I created something and got error number xyz, it's pretty hard to say anything then: use the debugger :-)
In general, on windows with MSVC, you have static libraries (only a lib file) and dynamic libraries (a dll which also might have a lib file for entry points and early binding). A dll may (if C-exported functions exist) also be used with late binding.
With minGW, a static library is an archive (.a) and a dynamic lib is an .so file (which might be linked early at compile time or loaded wia LoadLibrary / dlopen and the function adresses might be resolved).
-
Hi Gerolf,
I finally managed to get the program running: I made the mistake of only testing the library with Dependency Walker, without testing the executable. For some reason, additional (missing) libraries appeared in that second search that didn't show up in the first one.
bq. if you run in srashes, you should use the debugger.
My knowledge of the debugger is limited to stepping through the code using a watch list, which doesn't seem to help me if the crash happens before the first line of main(). What do you recommend?
bq. With minGW, a static library is an archive (.a) and a dynamic lib is an .so file
Perhaps I misunderstand, but I'm finding that MinGW creates DLLs. Aren't .so files restricted to *NIX environments?