2

We are using a 3rd party library that we build our code with. This library has both a 32-bit and 64-bit dll and lib. Both the 32 bit and 64 bit versions have the same name. Our software is expected to be built for both 32 bit and 64 bit and depending on the version it is naturally supposed to link to the corresponding version of the 3rd party tool. The problem is that we only have a single 3rd party include folder in our solution structure (no sub folders for 32 bit or 64 bit) so I can not place both versions in there without changing the name of one. I was told that if I change both the dll name and the corresponding lib name (example: add 64 to the 64bit dll and lib name) everything will still work and load automatically but to me this seems like it would not work. I am actually having a strange problem starting the 64bit app right now. Weird thing is that there is apparently another case where this approach worked for us before. So how is this work generally anyway? Can I change the name of a lib and a dll and as long as I link my code to the new name? Or will the dll not be loaded correctly at runtime?

virtore
  • 161
  • 1
  • 9
  • how *dll* related to build process ? you can change *lib* name, but not *dll*, if i correct understand - *lib* file correspond to *dll* – RbMm Jul 31 '18 at 19:54
  • Well dll is not related to build, I was just wondering if I change the lib name what dll be loaded or if it has anything to with that at all. How does the program know what the name of the dll is that it is trying to load? – virtore Jul 31 '18 at 20:02
  • name of dll was internally in lib. if you change external name of lib - this nothing changed. you can free change lib name. when you use import library - here exist info that some function `fn` imported from `some.dll`. as result in your binary will be import entry generated for `some.dll`. external name of lib not affect this at all. important only it internal context – RbMm Jul 31 '18 at 20:16

1 Answers1

1

If I understand this correctly, I believe that just changing the name of the .lib will be sufficient. The import library contains the name of the .dll it was built for. Therefore, when linked the final executable will still attempt to load the correct .dll.

This does assume, of course that your deployment installs the correct .dll when the application is installed, but all things considered, I'd be extremely surprised if it did not.

dgnuff
  • 3,195
  • 2
  • 18
  • 32
  • 1
    *the import library contains the name of the .dll it was built for.* - yes. this is true. even for every separate function - separate dll name. import library containing pairs - . formal can be multiple dlls name in single lib, but usually - all it the same – RbMm Jul 31 '18 at 20:18
  • @RbMm tyvm. Edited to reflect this. It's been a long long time since I dug around at this level. Since I normally build with the standard Visual Studio layout, I automatically have separate 32 and 64 bit directories for everything. – dgnuff Jul 31 '18 at 20:21
  • At the risk of getting asked to take this to private chat ( :) ) does that means in theory at least that one import library could be used for multiple `.dll`s? More as an academic curiosity, because in all honesty I can't see a real world use case for this. – dgnuff Jul 31 '18 at 20:22
  • 1
    yes, single library format support several dll. you can simply open any lib in any editor. even in notepad. and view that dll name exist multiple times here. however i also never view that lib containing different dll names – RbMm Jul 31 '18 at 20:26