I apologize for yet another non-fortran programming question.
I have a DLL & LIB file pair. I would like rename them, but don't have the source code. I tried merely renaming the two files and was able to rebuild my fortran app that calls its routines, but at run time my app is still looking for the original name. Are there other steps I need to do?
The import library (presumably the LIB file you have is the import library for the DLL) has the name of the DLL hardcoded inside it.
(A lib file can be an import file for multiple DLL's, a lib file can also contain a mix of imports and static code.)
The ways of working around this (that I can think of - build a new lib from a def file that forwards to the newly name DLL?) are non-trivial. Do you really need to rename the DLL?
Brian, it is troubling to see you operating in a half-blind mode in this and other numerous posts. Why do you have to make changes in one part of your project before you have thought through what the consequences of those changes are likely to be? And, if you fearlessly plunge ahead, why should failure not be the most frequent outcome?
Merely changing the name of a file does not change its contents. Putting the label "sugar" on a salt shaker does not make the contents sweet. Changing the name of a LIB file does not change the names of the exported routines in the import library that the linker uses to build your EXE. The import library file will still contain the same name of the DLL as the name used when the DLL/LIB pair were built. Your EXE, built using the import library, will still attempt to access the DLL using the DLL's old name.
Please sit back in your chair, and spend some time to ponder on how changes to various entities such as file names, routine names, etc., can affect the functioning of the various parts of a software project.
thanks for the reply, mecej4 - if it seems I don't know what I'm doing, you are absolutely correct. Lost in the fog is another way to put it.
There are multiple factors behind my query about DLL file names.
I have DLL's from multiple vendors, all of whom provide win32 and x64 versions (I ship both 32 and 64 bit versions of my app to support both versions of Office). Some vendors give the two versions different file names (typically with x64 inserted). One vendor gives them with identical names. So I wanted to put x64 into the name so I could manage their DLL's like the others.
Until recently, these DLL's were called only from Excel VBA, which gave me total freedom to rename DLL files. Now, however, I'm trying to call one DLL from another DLL, and the use of identical names introduces a win32/x64 naming conflict.
Since I now know I can't change the name, I will live with it. After first getting everything working in win32 flavor, I moved on to x64. I was hoping that would take a day or two. I'm well past that and still struggling. I may not live long enough to finish this.
If you are trying to deploy two DLLs with the same name to the same directory, then ... don't do that. Stick them in different directories. Both directories can be on the path (if they need to be) - the operating system will do the right thing. But typically users will only need one of the two variants anyway.
Otherwise, please elaborate on why a common name for a 32 bit and a 64 bit DLL is causing strife.
That is correct, "most" users need only one. Which one is determined by the bits of Office/Excel. My app installer detects the bitness of Excel, so some modifications are in store to install only the appropriate set of files. Before doing that I need to get x64 building and running satisfactorily. I've made good progress on that tonight, but can't work it any more until the weekend.
Installers can manage renaming files depending of the environment, language... IE renaming lib_x64.dll to lib.dll during installation process in x64 mode and so on.