Yeah, I actually googled around for this within the last month or two and found this: Stack Overflow linky (and there's a nice link to Microsoft Support there too) (note with these you create a new import library (.lib); you don't actually modify the original). The interesting instruction steps are:

From How To Create 32-bit Import Libraries Without .OBJs or Source
Given a .DLL with functions exported via a C interface, you can create an import library by following these steps:

1. Use DUMPBIN /EXPORTS <.DLL file name> to obtain the list of exported symbols for the .DLL in question. The symbols appear in the "name" column of the table whose headings are "ordinal hint name."
   
2. Create a .DEF file that contains an EXPORTS section with the names of the functions listed in the "name" column of the DUMPBIN output.
   
3. For _cdecl functions, the symbol appears just as it would when used in the calling program. Just place this symbol in the EXPORTS section of the .DEF file.
   
4. Use LIB /DEF:<.DEF file name> to generate the import library and exports file. The base name of the import library will be the base name of the .DEF file. Use /OUT: to control the output library name.
   

[/quote]

I don't know if there's a tool/script out there that will automate all this for you, so you may have to write one.

If you have access to the compiled .obj files, you can just re-link the objs instead of doing what the above links suggest.

I forgot to mention I'm using MinGW/GCC 4.6.3, not Visual Studio.

Sorry, I don't know why I assumed that. Here's a link for doing it for MinGW.

@Cornstalks: I do have the compiled .o files, the .a with the wrong name, and the compiled .dll.
Excellent idea re-linking the objects. Just tried it on a few, after some monkeying around, and I think it's working, though sometimes the filesizes being outputted are different (sometimes by more than a little) from the original DLLs Boost generated making me think some of the symbols are being missed.

Hmmm... you'll have to make sure the command parameters are exactly the same. For example, if you're using make, you can do [font=courier new,courier,monospace]make V=1[/font] to see what the exact command is for linking things, and then just copy 'n' paste the linking command with the changes you need. Usually ld or ar are used in linking stuff. If you're using [font=courier new,courier,monospace]ld[/font], just change the output DLL name (and be sure to pass [font=courier new,courier,monospace]--out-implib file [/font]to generate an import library (.a) (or you can pass [font=courier new,courier,monospace]--output-def file [/font]which will make a definitions file (.def) that can be used to make an import library later)). If you're using [font=courier new,courier,monospace]ar[/font], you're make a static library so an import library is useless and it won't make one, so no need to worry about this one. Another common linking tool is libtool, but I have less experience with that.

I'd say first try krippy2k8's solution for all you can, then try making an import library from the DLL, and then try relinking the object files.

I've been doing this too and as I had some almost def-creating tool code already written, I glued it to dlltool and link to automate the two manual methods outlined above. It's here if anybody wishes to use it. You give deflibcreator.exe <name>.dll and an optional output dir, and should get <name>.def, lib<name>.a, <name>.lib & <name>-x64.lib. The source is in there too in case somebody desperately needs Itanium libs or support for another compiler suite.