anand3162,
I have been following this thread. I don't see a good reason for multiple dll's. You said:
I do acknowledge that, I can combine ALL the subroutines into 1 .for file and make a DLL of that .for. However, my actual programs are all several thousand lines, so that makes code maintenance troublesome.
I don't see why having all .f90 files in the one dll should cause problems with code maintenance. FTN95 uses only 1 .dll and the build procedure for multiple source files is easy to do. If you want to to build using a single file, then you can write a file that consists of lots of includes, such as: all.f90 include 'f1.f90' include 'f2.f90' ... include 'f998.f90' include 'f999.f90'
Then you can compile all to 1 .obj file as ftn95 all.f90 producing all.obj which can then be converted into all.dll using slink My preference would be to manage all the .obj files in slink and have a single .dll to supply to your client.
For code support with FTN95, I prefer to use /debug which provides a good traceback when errors occur. I am not sure if that will work with a .dll (is the symbol table included in this way?) or if you wish to provide all this code structure information in a .dll. It is a very useful feature when supporting a run version. I typically use /debug for most code, removing it for only a few compute intensive routines.
John