Code Retard » C/C++

Generate a .lib from a DLL with Visual Studio

adm_snackbar — Wed, 21 Jan 2009 15:43:00 +0000

Oftentimes programmers have to deal with external third party DLLs that their software rely on to function. This is both smart and useful because as long as the DLL interface remains the same, externally linked DLLs can be easily swapped in and out without having to recompile and rebuild code. However, linking code in Visual Studio with an external library requires that a .lib file exist – the DLL is actually not sufficient for this task. Fortunately, there is a way to generate a .lib from a DLL with Visual Studio. Creating the .lib file is a bit like reverse engineering the DLL’s symbols.

Regardless of your Visual Studio version, whether it’s for 2003, 2005, or 2008 .NET, open up the Visual Studio Tools command promopt (something like Start -> Program Files -> Microsoft Visual Studio -> Visual Studio Tools -> Visual Studio Command Prompt).
If you have a .def file for your DLL, you can skip this step. Otherwise if your DLL did not ship with a .def file, you have a bit of work ahead of you. You cannot generate a .lib without a .def file first, sorry. To generate a .def file from a DLL, execute the dumpbin command to extract the function names from your DLL. In our example, we will be building from sqlite3.dll.
dumpbin /exports C:\path\to\sqlite3.dllThe output appears below:
The function names boxed in red are what you need to care about. Copy just the function name text into a new file with .def extension. Start the new file with "EXPORTS” without the quotes and then have each function on its own line like this:
EXPORTS sqlite3_aggregate_context sqlite3_aggregate_count sqlite3_auto_extension sqlite3_bind_blob sqlite3_bind_double sqlite3_bind_int sqlite3_bind_int64 ...
With your new definition file in tow, in the command prompt you can execute the lib command to finally generate the .lib file:lib /def:C:\path\to\sqlite3.def /out:C:\path\to\sqlite3.lib /machine:x86
This generates the .lib file you can use to link with in your project file. Note that the /machine argument can take any number of machine configuration so be sure to choose the correct one. To get a list of all machine types, simply type “lib” by itself. Here is the usage below for your edification:
usage: LIB [options] [files] options: /DEF[:filename] /EXPORT:symbol /EXTRACT:membername /INCLUDE:symbol /LIBPATH:dir /LIST[:filename]
/MACHINE:{AM33|ARM|EBC|IA64|M32R|MIPS|MIPS16|MIPSFPU|MIPSFPU16|MIPSR41XX| SH3|SH3DSP|SH4|SH5|THUMB|X86} /NAME:filename /NODEFAULTLIB[:library] /NOLOGO /OUT:filename /REMOVE:membername /SUBSYSTEM:{CONSOLE|EFI_APPLICATION|EFI_BOOT_SERVICE_DRIVER| EFI_ROM|EFI_RUNTIME_DRIVER|NATIVE|POSIX|WINDOWS| WINDOWSCE}[,#[.##]] /VERBOSE

And if you came looking for sqlite3.lib we just saved you a lot of time.

SQLite with C++ Example: A Compact Serverless Database Alternative

adm_snackbar — Wed, 10 Dec 2008 05:26:17 +0000

Have you got an application you’re working on that requires the power to store and query data of a SQL database but don’t need the hassle of setting up a client and server solution? Today, let us introduce you to SQLite which was made just for you. Besides being complete free, it’s a small and fast library that acts as a SQL database wrapper to a plain text file that sits locally in your application. What this means is you can create and enforce all the great structured tables in your database design as well as construct intricate data queries just like you do with any server-backed SQL database, except your database is just a local file – no server or client architecture needed. From the SQLite website:

SQLite is a in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private. SQLite is currently found in more applications than we can count, including several high-profile projects

SQLite is easy to set up with Tcl and C/C++ interfaces and boasts a powerhouse of a user base including Adobe, Firefox, Microsoft, Apple, Google, and McAfee, just to name a few.

Just to show how easy SQLite is to use in a C++ program, here are a few lines of code that will help you understand how easy SQLite is to use and how it might be a good fit for your needs:

#include sqlite3* db; char* db_err; int main() { sqlite3_open(“my_db.sql3”, &db); sqlite3_exec(db, "create table 'helloworld' (id integer);", NULL, 0, &db_err) sqlite3_close(db); }

And that’s a wrap. You pass any valid SQL query to the sqlite3_exec() function to do all your database manipulation. Data retrieval is passed via the parameters in a user-specified a callback function (in this example it was not used and was thus NULL). At any rate this simple example should be enough to help you get started with SQLite for your new project.

Switching from Static to Dynamic Linking

adm_snackbar — Fri, 21 Mar 2008 15:59:43 +0000

Recently I had to modify a library to use dynamic linking in order to cut down on its size. Originally a 8MB file, I was looking at reducing the size to 1.3MB. Pretty great right? So why not dynamically link every time? Well, there are certain times when static linking, though it increases the size of your library, might be preferable. For example, your library may be using some obscure third-party library that your customer does not have. If you dynamically linked this, you’d either require the customer to also have this library on his host, or else ship the third-party library with your own. Perhaps due to licensing reasons, incompatible versions or unavailability, this may not always be possible or even ideal. In my case, the third-party library was 10MB. Shipping it with my 1.3MB library would actually have a net increase in total package size. But since I was actually shipping several of my own smaller libraries which all used to statically link the third-party library, eventually the savings overcame the gain.

To do this is a matter of modifying your Makefile, there is no code change necessary unless you plan to call some functions in the third-party library, in which case you’ll need to use dlopen(). For me there was nothing this complicated, I just needed my third-party header files to be defined… no function calls needed. The original Makefile was doing something like this:

g++ -c -o main.o main.cpp
g++ -L/home/user/tool/static-libs -lstatic_third_party_lib -o main main.o

To make it dynamically link, you first need to find the dynamic version of the third party library. Usually static libraries have a *.a extension. Dynamic libraries have a *.so extension. Once I found the path to the dynamic library, I simply modified my Makefile like so:

g++ -c -o main.o main.cpp
g++ -L/home/user/tool/dynamic-libs -ldyn_third_party_lib -o main main.o

In this way, your own library will be smaller but you have now imposed a requirement on your user. Regardless of how you get your customer the third party lib, he will have to modify his LD_LIBRARY_PATH to include a path to it. But this was not good enough for me, my requirement was to rid the library of that dependency. So what do to? There’s another option that is generally considered good programming convention that you should always use with the -L option, and that is –rpath. This option specifies the run-time path that your library will look for the third-party library, avoiding the need for the customer to set LD_LIBRARY_PATH. The Makefile would be extended like so:

g++ -c -o main.o main.cpp
g++ -L/home/user/tool/dynamic-libs -Wl,--rpath=/home/user/tool/dynamic-libs -ldyn_third_party_lib -o main main.o

Basically, any time you use -L, use -Wl,–rpath with the same path. This is great if you know the absolute path where it will be installed on your customer’s machine, but this may not always be true. For our software, the user is free to install it anywhere, and thus this option would not be useful. There is one more trick you can play to get this to work, and that is to use a relative path using the $ORIGIN variable. This is self-defined to be the path in which your library resides, you do not have to define it in your Makefile. Use it like so:

g++ -c -o main.o main.cpp
g++ -L/home/user/tool/dynamic-libs -Wl,--rpath=\$$ORIGIN/../../my/own/path/dynamic-libs -z origin -ldyn_third_party_lib -o main main.o

For you guys developing on SunOS, replace the -Wl,–rpath= option with -R, like this:

CC -c -o main.o main.cpp
CC -L/home/user/tool/dynamic-libs -R\$$ORIGIN/../../my/own/path/dynamic-libs -z origin -ldyn_third_party_lib -o main main.o

For you Windows guys, how did I manage to hold your attention until here?

Useful Quick References

adm_snackbar — Tue, 18 Mar 2008 05:12:39 +0000

Whether you program in C++ or code in HTML, you’ve probably encountered a quick reference (”quickref” for short) at some point in your career. These handy guides aren’t meant to teach newbies how to use the language, but are more like the index at the back of your textbook except condensed and consolidated in a few pages. Today’s post lists a few useful quickrefs that I’ve accumulated over the years. Here they are sorted by category:

For the web:

Web Designer’s HTML Card (credit: VisiBone)
Javascript Quickref v1.03 (credit: explain.th.at)
CSS Quickref (credit: deepx)
PHP Quickref (credit: ilovejackdaniels.com)
MySQL Quickref v4.0.2a (credit: deepx)
JSP Quickref (credit: Allaire)
Ruby Language Quickref
Ruby Library Quickref

For Microsoft:

C# Quickref
MFC Quickref (credit: He)
VB.NET Quickref (credit: Kellerman)

For C/C++:

ANSI C Quickref v1.3 (credit: Silverman)
STL Quickref v1.26 (credit: Medini)

For Configuration Management:

CVS Quickref v0.1 (credit: Ford)
SVN Quickref v28 (credit: Sobaniec)

For Hardware:

Verilog Quickref (credit: Qualis)
SystemC Quickref (credit: Transfer)