Creating interfaces for compiled libraries

[dwwade]

I have a vendor who I purchase a yearly license from which the expiration date/license keys are in a compiled library. This means that I must recompile software that I have verified to work every year regardless of any other requirements. As this is the case, I'd like to dissociate my main programs that use this library from the recompile required for the license. The library is extensive, written in FORTRAN 77, and has many subroutines, functions and common blocks. I would like to create a DLL from this compiled library. Is there a tool that would extract the header information from the compiled library so that I don't have to make all of the DLL declarations by hand?

-D

[Steven_L_Intel1]

There is, sort of. If you add the option /gen-interfaces the compiler will create individual __GENMOD.f90 files that contain the interface for each subroutine and function. These can form the basis of a module that declares the interfaces to the routines in the DLL. But you'll also need to add !DEC$ ATTRIBUTES DLLEXPORT directives to each actual routine (or use a .DEF file as long as you don't want COMMON blocks visible from the application.) in order to build a usable DLL.

[dwwade]

I'm going to admit that I'm a bit clueless about IVF and the VS2005 interface come into play. I'm just now being forced to switch from CVF. Can you give me an example?

[Steven_L_Intel1]

The interface really isn't all that different from that of VS98/CVF - some things are in different places. You should read Migrating from CVF. But the simple thing is this. Right click on the Fortran "project" name in the "Solution Explorer" pane (this is the one with the blue icon next to it, not the solution name at the top level) and select Properties. Select Fortran > Command Line. In the field for additional options, type:

/gen-interface

and then build the library. You'll find lots of .f90 files in the Debug (or Release) folder - these are your interfaces. Collect their content into a module or whatever you want. This is a starting point - you may need some tweaking - but it will give you a big head start.

[dwwade]

I think I'm finding the interface changes a bit daunting at the moment. I got an error and I'm not sure what to do since it seems to be at the linker phase instead of the compiler phase. It seems that no .90 files are created.

Warning 1 warning LNK4001: no object files specified; libraries used LINK
Warning 2 warning LNK4068: /MACHINE not specified; defaulting to X86 LINK
Error 3 error LNK2001: unresolved external symbol __DllMainCRTStartup@12 LINK
Error 4 fatal error LNK1120: 1 unresolved externals Debug\DLLmap.dll

[mecej4]

I see a couple of points in what you wrote that are puzzling.

If the library has a routine containing license keys, then only that routine needs to be recompiled when the keys change, only the resulting .OBJ file needs to be used to replace the old one in the library, and your application needs to be linked with the updated library.

If the file containing the license key is INCLUDEd in a number of library routines, the corresponding files need to be recompiled and the library updated. Again, there is no need to recompile your code -- a relink would suffice.

In either case, your sources do not need recompilation, and whether to build and use explicit interfaces to the library routines is a separate issue.

If you want to link against a DLL instead of the static library, and your license agreement permits you to redistribute the DLL, you need to build a list of exported symbols in a .DEF file and use that .DEF file to build the .DLL and the corresponding import library.

The DUMPBIN utility (with many versions of the Microsoft SDK, this is just a renamed copy of the linker) can help you to build the .DEF file.

[dwwade]

I hesitated to explain too much as I'm oft accused of being boring. Let me explain in a bit more detail:

My IT department in the past year did not let me have my old copy of CVF installed on my new refreshed computer. They had been threatening to do this for years, but I assumed I could keep it since we'd already paid for it. I was wrong. This means that I will have to perform the switch to IVF with all of my various analysis tools, some of which haven't required actual code edits in 5 or 6 years. I've never kept my full /release or /debug directories after I have a working version (I use the clean build function), particularly when I do the cvs update. Maybe I could have used the compaq visual fortran objs with the VS2005 linker, but that is too late now.

I have complained to my vendor that they will not give me even just an updated key within the library, they compile in the "latest and greatest" code (which always makes me nervious as it requires me to do quite a bit of functionality testing to look for regression before getting back to real work).

My vendor for this library uses only standard F77 routines for the actual product. I believe that this so that they can release the code for many platforms without much effort. Obviously the USB dongle does require that they have some special library calls specifically for windows, but this is setup as a modular thing so that they can avoid most of the headache of maintaining many platforms. As this USB dongle is supplied by a 3rd party with a license management software that has to be seperately installed for which they have to generate key values, I have asked that the key be turned into a text file so that I can just put it in the same directory as the analysis tools. They have refused.

The license I have from the vendor doesn't preclude me from creating a DLL as long as I do not attempt to defeat the USB dongle software and thus use a program generated from the library that can operate without the dongle. I have specifically asked this in the past, and while they are unwilling to put in any effort creating a DLL, they have said specifically they don't care if I create one.

I have looked at the dumpbin utility and I'm not exactly sure how to get it to give me the functions/subroutines/common blocks. As I said before, I need the common blocks and it was explained above that those can't be used when using just the .def file. If you do know of other tricks in this, I'd really appreciate it.

[edit]

I realize that I forgot to mention why a DLL rather than statically linked. I'm particularly frustrated at this moment at my IT departments decision and when they decide to say that IVF is no longer the tool of their choice, I want to have everything abstracted across the library boundaries so that I can just figure out how to recompile the library into a DLL rather than having to figure out how to force my tools to work in yet another compiler.

-D

[mecej4]

I think that you have a number of constraints some of which are beyond your control, and there does not seem to be an obvious solution that you could implement without expending much effort.

This thread addresses sharing data between a DLL and programs that use it:

http://software.intel.com/en-us/forums/showthread.php?t=81698

You go too far in your expectation that building a DLL would cut the ties between your application, the vendor library and the compiler that your IT people thrust upon you. If any of the routines in the (proposed to be built) DLL do I/O, that will create a stiff dependency of the DLL and everything else on the compiler's runtime. Secondly, the linkage to DLLs is already different for X64, and you will probably need to make a transition one of these years. Will your vendor provide an X64 version of the library?

Perhaps your are at a cross-roads where you should re-evaluate your use of dongles (I thought they were mostly gone from use) and look for ways to secure independence from the vendor library.

[dwwade]

I think your first point is absolutely correct, as very few things are within my control, which might be giving me an ulcer ;).

As for switching products, this library is for a highly specialized analysis library used in my field. It has the equivalent of something like 70 PhD years invested in it by some of the smartest people I know of in this field. As much as I'd love to be able to cut the ties of the $$$$ dollar per year license maintanence, I don't have the knowledge or experience to create these from scratch, as this is only a peripheral discipline used by mine, but not actually part of mine. The only way to cut the dongle tie would be to get a site license for $$$$$$ dollars that has an even higher than the current yearly license renewal expense. As there are only a half dozen people who use it, the company can't justify that expense. Also there are many pieces of somewhat specialized software that use USB dongles to lock down how many copies of a program are used. Lightwave 3D for instance is a good example and they just made the shift from 32 -> 64 bit.

I read through the bits in the manual (and several other websites) on sharing fortran data via DLLs, and since this is a library, couldn't I make a module interface that has the common blocks defined in it, if I were willing to do this the hard way (ie making interface blocks for each item then declaring it using the !DEC$)? I'm slightly confused after reading your link. I thought that in 32 bit space, that DLLs didn't necessarily get shared anymore like they did in Windows 9x. If I'm running two of my programs that would use this DLL I would need them to not share the data and procedures between each other, as that would be very very bad. Also, when you say I/O makes it dependant, I'm not sure what you mean. This library writes out scratch files at various intervals. Can a DLL not write to the disk like this?

I'm pretty sure that we can still run 32 bit programs under 64 bit Windows, so as long as whatever compiler they force on me can still make 32 bit DLLs, I'm assuming that I could still use the software that works and only upgrade as absolutely required.

My boss has given me the rest of the month to update my code and perform the analyses that he asked for, so if I have to go through and just make it work in IVF and forgo any dissociation I'll do it.