• Advertisement
Sign in to follow this  

Renaming DLLs and still linking properly

This topic is 2010 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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. [img]http://public.gamedev.net//public/style_emoticons/default/mellow.png[/img]

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: [i]libboost_filesystem-mgw46-1_50.dll[/i]

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: [i]libboost_filesystem.dll[/i] 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!

Share this post


Link to post
Share on other sites
Advertisement
Yeah, I actually googled around for this within the last month or two and found this: [url="http://stackoverflow.com/questions/280485/how-do-i-rename-a-dll-but-still-allow-the-exe-to-find-it"]Stack Overflow linky[/url] (and there's a nice [url="http://support.microsoft.com/kb/131313"]link to Microsoft Support[/url] there too) (note with these you create a new import library (.lib); you don't actually modify the original). The interesting instruction steps are:

[quote]
[i]From [url="http://support.microsoft.com/kb/131313"]How To Create 32-bit Import Libraries Without .OBJs or Source[/url][/i]
Given a .DLL with functions exported via a C interface, you can create an import library by following these steps:[list=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."
[*]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.
[/list]
[/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. Edited by Cornstalks

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='Servant of the Lord' timestamp='1342736059' post='4961086']
I forgot to mention I'm using MinGW/GCC 4.6.3, not Visual Studio.
[/quote]
Sorry, I don't know why I assumed that. [url="http://www.mingw.org/wiki/CreateImportLibraries"]Here's a link for doing it for MinGW[/url].

[quote name='Servant of the Lord' timestamp='1342736059' post='4961086']
@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.
[/quote]
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 [url="http://linux.die.net/man/1/ld"]ld[/url] or [url="http://linux.die.net/man/1/ar"]ar[/url] 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 [i]file [/i][/font]to generate an import library (.a) (or you can pass [font=courier new,courier,monospace]--output-def [i]file [/i][/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.

Share this post


Link to post
Share on other sites
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. [url=http://www.airesoft.co.uk/files/deflibcreator.zip]It's here if anybody wishes to use it[/url]. 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.

Share this post


Link to post
Share on other sites
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. [img]http://public.gamedev.net//public/style_emoticons/default/laugh.png[/img]

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

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

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


Apparently, the default for Boost is to generate every variation of every library (fine), and if you use[b] --layout=system[/b] 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. [img]http://public.gamedev.net//public/style_emoticons/default/wacko.png[/img]

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

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

Thanks for the help everyone. Edited by Servant of the Lord

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement