8 replies to this topic

[Servant of the Lord]

I'm using a few DLLs in my project that have very verbose names. I would like to rename them, but the problem is that the linker file (libxyz.a) would link to the wrong name.

Without recompiling the library, is there some way I can manually - or by using a tool - give it a different DLL name to look for?

For example, one of the DLLs I want to rename is from Boost: libboost_filesystem-mgw46-1_50.dll

It's providing good information in the name (the compiler, compiler version, and the Boost version), but not information I'm particularly needing. I'd like to rename it to just: libboost_filesystem.dll and have my project still find it.

So is there a tool that I can use to just edit the .a file to give it a new name for the DLL?

Thanks in advance!

[Cornstalks]

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:

• 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."
• Create a .DEF file that contains an EXPORTS section with the names of the functions listed in the "name" column of the DUMPBIN output.
• 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.
• 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.

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.

Edited by Cornstalks, 19 July 2012 - 11:35 AM.

[krippy2k8]

This doesn't answer your question directly, but FYI you can build the boost libraries without all of the version and compiler information by passing the following switch to your bjam command:

--layout=system

Then the library file will reference the unversioned DLL/so name.

[Servant of the Lord]

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


@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.

@krippy: Thanks, that saves me alot of time.

[Cornstalks]

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 make V=1 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 ld, just change the output DLL name (and be sure to pass --out-implib file to generate an import library (.a) (or you can pass --output-def file which will make a definitions file (.def) that can be used to make an import library later)). If you're using ar, 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.

[adeyblue]

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.

[Servant of the Lord]

Thanks, adeyblue, I've been messing around all day with g++ and dlltool trying to get them to work, and succeeding to various degrees, but try as I might, there was always something that didn't line up properly. Wish I had your tool eight hours ago.

@krippy: I've been trying for the past three hours, and finally got it ten minutes ago. There's a trick with --layout=system that has been throwing everything off:

bjam --toolset=gcc
...it still installs everything (despite --layout=system supposedly being the default).

I tried explicitly stating:
bjam --toolset=gcc --layout=system
...and it gives a bunch of errors about duplicate names ("error: Duplicate name of actual target: <pstage\lib>libboost_system.a").


Apparently, the default for Boost is to generate every variation of every library (fine), and if you use --layout=system then all the library variations get named the same thing and overwrite each other, hence the duplicate name messages.

So it seems the proper method (if you don't want the weird names), is to generate each variation type individually, and then move the resulting libraries before you generate the next variation.

So:
bjam --toolset=gcc --layout=system link=shared variant=release
(copy the files to a new location)

bjam --toolset=gcc --layout=system link=shared variant=debug
(copy the files to a new location)

Thanks for the help everyone.

Edited by Servant of the Lord, 19 July 2012 - 07:37 PM.

[krippy2k8]

Yeah you can't build all variations of the libraries with the system layout with one command, but you can streamline it a bit by setting the --stagedir option in bjam. I usually use a script to execute commands like this:

bjam --toolset=gcc --layout=system link=shared variant=release --stagedir=/path/to/release/shared stage
bjam --toolset=gcc --layout=system link=shared variant=debug --stagedir=/path/to/debug/shared stage

I make that a habit even when building with versioned library names to reduce clutter.

Also FYI --layout=system is only the default on Unix, --layout=versioned is the default on Windows.

Edited by krippy2k8, 19 July 2012 - 08:53 PM.

[Servant of the Lord]

Ah, thanks, I was wondering about that. I keep reading it was the default, but it obviously wasn't defaulting to it.