Replace dllwrap with a Working MinGW DLL Build

x86_64-w64-mingw32-dllwrap still runs on an installed Debian or Ubuntu toolchain, but it warns you the moment you ask for help: it is deprecated. This guide runs a harmless interface check, then shows the safer path for a new Windows DLL build. The short version: dllwrap is a deprecated wrapper, not a tool to introduce into new build scripts.

Allow about fifteen minutes for the checks below. You need a shell and the binutils-mingw-w64-x86-64 package. The examples inspect the command and never create a DLL, alter a linker configuration, or need elevated privileges.

1. Confirm the installed command and package

Check which executable your shell would run, then record the package version. Both are ordinary read-only checks:

$ command -v x86_64-w64-mingw32-dllwrap
/usr/bin/x86_64-w64-mingw32-dllwrap
$ dpkg-query -W -f='${Package} ${Version}\n' binutils-mingw-w64-x86-64
binutils-mingw-w64-x86-64 2.41.90.20240122-1ubuntu1+11.4

That version matters when comparing output with another machine. This guide was checked against GNU Binutils 2.41.90.20240122, packaged as shown above. Your distribution may ship a different build and different warning text.

2. Read the warning before using the tool

Ask the installed executable for its help:

$ x86_64-w64-mingw32-dllwrap --help
Usage x86_64-w64-mingw32-dllwrap <option(s)> <object-file(s)>
  Generic options:
   @<file>                Read options from file
   --quiet, -q            Work quietly
   --verbose, -v          Verbose
   --version              Print dllwrap version
   --implib <outname>     Synonym for --output-lib
  ...

The full output also lists legacy controls for the driver, dlltool, entry point, image base, export files and import libraries. The important line is not an option, though. The installed program warns it is deprecated and points you at gcc -shared or ld -shared instead.

The manpage installed with this package is even blunter. It calls dllwrap an ancient PE DLL generator, says not to use it for new code, and points at ld --shared. Treat that as the compatibility boundary for this guide. A successful help command is not a recommendation to keep dllwrap around indefinitely.

3. Verify the version without building anything

Use --version to get the program's own identity:

$ x86_64-w64-mingw32-dllwrap --version
GNU x86_64-w64-mingw32-dllwrap (GNU Binutils) 2.41.90.20240122
Copyright (C) 2024 Free Software Foundation, Inc.
...

The command may print the deprecation warning before the version banner, which is expected for this installed build. That version output is a useful diagnostic when a build log from an older machine seems to accept a different option set.

Skip sudo entirely here. Running dllwrap as root would not make an obsolete interface more compatible, and it would only make files from a later experiment harder to remove as your normal user.

4. Test option handling with a dry run

Before connecting dllwrap to real object files, use --dry-run with an explicit output choice. This still is not a DLL build, but it demonstrates an easy failure trap:

$ x86_64-w64-mingw32-dllwrap --dry-run --output-lib /tmp/example.a /tmp/example.o
x86_64-w64-mingw32-dllwrap: WARNING: x86_64-w64-mingw32-dllwrap is deprecated, use gcc -shared or ld -shared instead
...

The object path above is a placeholder, replace it only with an object file you have already built. The output library sits under /tmp so an experiment cannot overwrite a project artefact. A dry run can still fail because the input is absent, or the installed wrapper cannot assemble a complete command from the arguments supplied. That failure is useful: nothing in your source tree has changed.

One confusing default shows up here: dllwrap needs an output choice such as --output-lib, its --implib synonym, or a DLL name through its legacy interface. Supplying only an object file is not a complete invocation on this installation.

5. Use the supported shape for a new build

For new code, move the link step to the cross C compiler or linker named by the warning. A representative compiler command is:

$ x86_64-w64-mingw32-gcc -shared -o example.dll example.o

This is a build example, so it needs a real example.o and writes example.dll to the current directory. Check the compiler is available and the object is the one you actually intend to link first:

$ command -v x86_64-w64-mingw32-gcc
/usr/bin/x86_64-w64-mingw32-gcc
$ test -r example.o && echo 'object is readable'
object is readable

Do not paste an untrusted filename into a build script without quoting it. If the object or output path contains spaces, quote every shell argument. Keep the output in a disposable build directory until the DLL has been inspected.

The manpage also names ld --shared. Use the linker directly only when your project already owns the complete linker inputs and flags, since the compiler driver normally supplies the language-runtime and startup details a compiler-led build expects. These are different workflows, so do not mechanically swap ld in for a dllwrap command and assume the result is equivalent.

6. Recover from a bad experiment

dllwrap and the replacement linker commands can write files, but need no elevated privileges when building in a directory you own. If a test created an unwanted file under /tmp, inspect it before removing it:

$ ls -l /tmp/example.a /tmp/example.dll 2>/dev/null
$ rm -- /tmp/example.a

If the replacement command fails, keep the diagnostic and inspect the object file, target architecture and link flags. A dllwrap warning is not evidence the object is valid, that exports are correct, or that the resulting DLL will load on Windows.