I'm creating a small .dll for some code I'll be reusing alot, and I'm not exactly sure how to make the .lib file. As I understand it, I'm supposed to have __declspec(dllexport) before any function that I want to be accessible outside of the DLL? I'm using it like this:

__declspec(dllexport) enum {...};

__declspec(dllexport) void MyFunc();

__declspec(dllexport) extern int MyInt;

Is this correct? My actaul functions don't have '__declspec(dllexport)' before them, only the predeclarations in the header file does. Still, my .lib file isn't being generated, so I'm not sure if I need to do something else or not. The DLL is merely a small wrapper around some SDL functions, so it has SDL included into it. Do I need to do something extra to ensure that it works correctly? It all compiles fine, but there is no .lib file.

That is very odd. Normally the EXP and LIB files are generated by default.

This is how I manually do it in MSVC++ .NET 2005:

1) Create new General > Empty Project. Save in, for example, D:\dev\dll_test
2) Open project properties. Go to Configuration Properties > General > Configuration Type. Change to Dynamic Library (.dll)
3) Create C++ source file, place code into file.
4) Compile.

The EXP, LIB and DLL files appear in D:\dev\dll_test\debug (Note: NOT in D:\dev\dll_test\dll_test\Debug as one would assume)

Example code I used:



Hope that helps!

I did as you said, and still didn't get a .lib file. But perhaps this is becuase of confusion on my part? I get a .def, .o, .a, .dll, .win, and .layout as well as the project file and the source file. .layout has to do with the project's layout, and .win is used when compiling, I believe. Is .a my lib file?

I'm using Dev C++ by the way. And my projects are selected as Win32 DLL.

The "problem" is that DEV-C++ does not generate MSVC++ compatible LIB files. I'm not familiar with the mechanics behind DEV-C++, but you could always try linking in the .o or .a files and see if it works.

Otherwise, what you will have to do (as far as I can best estimate), is load the library and its functions at runtime:

1) Use the Win32 API function LoadLibrary to obtain an OS-level handle ID to the DLL file.

2) Use the Win32 API function GetProcAddress to obtain a pointer to your function.

3) At application exit, use the Win32 API function FreeLibrary to release the DLL's handle ID.

This involves a bit of function pointer syntax. The best documentation and example for this that I've found are from MS:

1) Go to msdn.com
2) Search for the documents: "Run-Time Dynamic Linking", "Using Run-Time Dynamic Linking"

So as you can see, the LIB files only really exist as a feature to ease the use of DLL files inside of one's applications, and are absolutely unnecessary.

This process of loading DLL/functions at runtime is actually my preferred method, even though I am using MSVC++. This way if a DLL or function does not exist, I can generate a nice error message instead of those nasty cookie-cutter "The application failed to initialize because it's missing a library file blah blah" messages. :)

Here is some example code for loading the DLL/function at runtime, in case the MSDN articles are a bit too obscure:

Thanks, I'll check that out. It seems linux can't use .LIB files, so Dev C++ creates .a and .o instead, even though I use windows. Ah well, they ought to work here also. Many thanks.

Quote:Original post by taby
Here is some example code for loading the DLL/function at runtime, in case the MSDN articles are a bit too obscure:

*** Source Snippet Removed ***

Many thanks! That's much more simpler than I'd have thought.

Quote:Original post by Servant of the Lord
Thanks, I'll check that out. It seems linux can't use .LIB files, so Dev C++ creates .a and .o instead, even though I use windows. Ah well, they ought to work here also. Many thanks.

As far as I know, other Windows compilers may or may not be able to export MS LIB format either. I just wanted to point out that it's more of a MSVC++ than a Windows "thing". :)

Yeah, I realize that, so my dlls ought to work regardless. Thanks for the linking runtime info though, as that may come in handy later.