How to generate an import library (LIB-file) from a DLL?

Is it possible to autogenerate a MSVC import library (LIB-file) from a DLL? How?

You can generate a DEF file using dumpbin /exports:

echo LIBRARY SQLITE3 > sqlite3.def
echo EXPORTS >> sqlite3.def
for /f "skip=19 tokens=4" %A in ('dumpbin /exports sqlite3.dll') do echo %A >> sqlite3.def

The librarian can use this DEF file to generate the LIB:

lib /def:sqlite3.def /out:sqlite3.lib /machine:x86

All of the filenames (sqlite3.dll, sqlite3.def, etc.) should be prepended with full paths.

I know the topic is old, but I still couldn't find a script or batch file anywhere on the Internet to do this. So based on Dark Falcon's answer, I've made this script, which you can save as dll2lib.bat and run:

REM Usage: dll2lib [32|64] some-file.dll
REM
REM Generates some-file.lib from some-file.dll, making an intermediate
REM some-file.def from the results of dumpbin /exports some-file.dll.
REM Currently must run without path on DLL.
REM (Fix by removing path when of lib_name for LIBRARY line below?)
REM
REM Requires 'dumpbin' and 'lib' in PATH - run from VS developer prompt.
REM 
REM Script inspired by http://stackoverflow.com/questions/9946322/how-to-generate-an-import-library-lib-file-from-a-dll
SETLOCAL
if "%1"=="32" (set machine=x86) else (set machine=x64)
set dll_file=%2
set dll_file_no_ext=%dll_file:~0,-4%
set exports_file=%dll_file_no_ext%-exports.txt
set def_file=%dll_file_no_ext%.def
set lib_file=%dll_file_no_ext%.lib
set lib_name=%dll_file_no_ext%

dumpbin /exports %dll_file% > %exports_file%

echo LIBRARY %lib_name% > %def_file%
echo EXPORTS >> %def_file%
for /f "skip=19 tokens=1,4" %%A in (%exports_file%) do if NOT "%%B" == "" (echo %%B @%%A >> %def_file%)

lib /def:%def_file% /out:%lib_file% /machine:%machine%

REM Clean up temporary intermediate files
del %exports_file% %def_file% %dll_file_no_ext%.exp

I'm sure the script can use improvement, but I hope it's useful.

For those who are on Linux and would like to create an appropriate import library (.lib) for a .dll produced by MinGW, there are again two steps involved:

• Create .def file from .dll
• Create .lib file from .def

Using MSVC, one could process the output of dumpbin /exports foo.dll. On Linux, you have to process the output of objdump -p (from binutils). The generated module definition file should look like:

LIBRARY foo.dll
EXPORTS
    your_symbol @1
     another_symbol @2
     ; ... et cetera

To convert the .def file to a .lib file, use llvm-dlltool (MinGW (binutils) dlltool is not suitable). Example invocation for a 64-bit library:

llvm-dlltool -m i386:x86-64 -d foo.def -l foo.lib

Explanation:

• -m i386:x86-64: generate a 64-bit library. Use -m i386 if you need a 32-bit library instead.
• -d foo.def: read exported symbols from file foo.def
• -l foo.lib: write an import library to foo.lib
• If a .def file does not contain a LIBRARY line, you have to append the -D foo.dll option (with just the filename and no directory prefix).

And here is a script to automate it:

# Given libxyz-1.dll, create import library libxyz-1.lib
make_implib() {
    local machine=$1 dll="$2" dllname deffile libfile

    dllname="${dll##*/}"
    deffile="${dll%.dll}.def"
    libfile="${dll%.dll}.lib"

    # Extract exports from the .edata section, writing results to the .def file.
    LC_ALL=C objdump -p "$dll" | awk -vdllname="$dllname" '
    /^\[Ordinal\/Name Pointer\] Table$/ {
        print "LIBRARY " dllname
        print "EXPORTS"
        p = 1; next
    }
    p && /^\t\[ *[0-9]+\] [a-zA-Z0-9_]+$/ {
        gsub("\\[|\\]", "");
        print "    " $2 " @" $1;
        ++p; next
    }
    p > 1 && /^$/ { exit }
    p { print "; unexpected objdump output:", $0; exit 1 }
    END { if (p < 2) { print "; cannot find export data section"; exit 1 } }
    ' > "$deffile"

    # Create .lib suitable for MSVC. Cannot use binutils dlltool as that creates
    # an import library (like the one found in lib/*.dll.a) that results in
    # broken executables. For example, assume executable foo.exe that uses fnA
    # (from liba.dll) and fnB (from libb.dll). Using link.exe (14.00.24215.1)
    # with these broken .lib files results in an import table that lists both
    # fnA and fnB under both liba.dll and libb.dll. Use of llvm-dlltool creates
    # the correct archive that uses Import Headers (like official MS tools).
    llvm-dlltool -m "$machine" -d "$deffile" -l "$libfile"
    rm -f "$deffile"
}

# Example invocations:
make_implib i386:x86_64 usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgnutls-30.dll
make_implib i386 usr/i686-w64-mingw32/sys-root/mingw/bin/libgnutls-30.dll

(Note that there is a bug in llvm-dlltool that produces a larger .lib file than necessary if the library name is longer than 15 characters. Aside from the size, it is fully functional though. This is fixed by https://reviews.llvm.org/D55860)

Tested with:

• llvm-dlltool from LLVM 7.0.0-1 (Arch Linux)
• objdump from binutils 2.31.1-3 (Arch Linux)
• dlltool from binutils-mingw-w64-x86 64_2.30-7ubuntu1+8ubuntu1 (Ubuntu 18.04)
• link.exe from Visual Studio 2015 14.00.24215.1 (Windows 7)

This script creates *.lib from *.dll passed in %1:

@echo off

setlocal enabledelayedexpansion
for /f "tokens=1-4" %%1 in ('dumpbin /exports %1') do (
    set /a ordinal=%%1 2>nul
    set /a hint=0x%%2 2>nul
    set /a rva=0x%%3 2>nul
    if !ordinal! equ %%1 if !hint! equ 0x%%2 if !rva! equ 0x%%3 set exports=!exports! /export:%%4
)

for /f %%i in ("%1") do set dllpath=%%~dpni
start lib /out:%dllpath%.lib /machine:x86 /def: %exports%

You could name it implib.bat and run: implib.bat C:\folder\mydll.dll which produces C:\folder\mydll.lib

> Is it possible to autogenerate a MSVC import library (LIB-file) from a DLL? How?

In addition to Dark Falcon's answer, Microsoft has published procedures at How To Create Import Libraries Without .OBJs or Source.

Microsoft's first procedure is the same as Dark Falcon's. The second procedure is a little more cumbersome, but it shows how to do it with an object file using stubs. It works with different calling convention and classes.

Here's the second procedure from the KB:

1. When "__declspec(dllimport)" is used in a prototype or declaration, change it to "__declspec(dllexport)."
2. For functions that do not return a value, for C functions in C source, and for C functions in C++ source code (used with the 'extern "C"' construct), replace the semicolon that terminates the function prototype with a matched pair of curly braces ("{}").
3. For C++ functions (global or member) that return a value, you must create a dummy body for the function, and return a dummy value of the proper type. (Not having a return statement in the function is illegal.) This goes for class member functions, as well. Keep in mind that the purpose of this procedure is to trick the LIB utility into generating the correct import library, so these dummy bodies have no effect.
4. For C++ classes, you can stub out the member functions by using the prototypes in the class declaration, as long as you disable function inlining when you compile.
5. Function arguments are usually just specified by type in a header file. For example, Geta(int). A dummy argument identifier must be specified when adding the dummy function body Geta(int x). Otherwise the error C2055 is generated.