Upgrading from CVF6 - libraries?

[keithmay]

Hello:

I'm upgrading to the Intel FTN product but have some concerns about "legacy" FTN DLLs made with CVF6. What do I need to worry about if I try to mix-and-match DLLs made with CVF6 and the INTEL product? I'm particulary curious/worried about the effect of run-time library calls (mainly for I/O) made by the two types of DLLs when used in the same application. The applications I'm building have both Fortran and VB mains. Any steers to documentation on this/these subjects greatly appreciated.

Mainnly my concern is whether I have to rebuild all the legacy DLLs - I'm working with a team where some members are "stuck" using CVF6. I want to upgrade but worry about using DLLs still maintained with CVF6.

[TimP]

The run-time I/O library calls won't match between CVF and recent ifort. There is an option for 32-bit ifort to make the calling ABI the same as CVF, and perhaps work with stdcall, but it's not the default, and won't fix the discrepancy in run-time libraries. As Steve explains below, with dynamic linking, and all .dll's available for each library, the linkage would allow each .dll to find its corresponding libraries.
If this were to work at all, each .dll would need to link to the corresponding run-time, and it would likely be necessary to close and reopen any files which are to be accessed by both run-times, when switching.

[keithmay]

Quoting - tim18

The run-time I/O library calls won't match between CVF and recent ifort. There is an option for 32-bit ifort to make the calling ABI the same as CVF, and perhaps work with stdcall, but it's not the default, and won't fix the discrepancy in run-time libraries.
If this were to work at all, each .dll would need to link to the corresponding run-time, and it would likely be necessary to close and reopen any files which are to be accessed by both run-times, when switching.

Many thanks tim18. I guess I have to brow-beat the other developers to upgrade as well. The work-around you mentioned of closing/re-opening all files is too ugly to contemplate.

I suppose this brings up a related question about how "re-usable" FTN DLLs are: they seem to have a particularly tight tie to the run-time libraries (especially for I/O). I haven't had to deal with this kind of issue with C/C++ - based DLLs before (maybe because there's some kind of standardization?). Any observations? I'll understand if you don't have the time/interest to reply. It's just a pet peeve of mine - I deal with mixed-language issues all the tiime and here I am trying to deal with an (almost) pure FTN environment and running up against walls. What's your take on that?

Thanks

K.

[TimP]

Intel C and C++, and, to an extent, Fortran, are specifically based on the include files and run-time libraries of the most popular C++ implementation for the corresponding operating system. This lends a degree of standardization, but Microsoft makes large enough changes from time to time that there isn't very good compatibility between VC6 as it stood at the end of the CVF era and current VC9, much less VC10, which seems likely to require significant changes to ifort once again. Even VC7.1 isn't viable with many currently supported Windows versions. At the source code level, Fortran retains excellent compatibility from CVF on through the latest compilers, more so than C++ did over that time period.
Likewise, linux sees changes from time to time, with mainstream builds of g++ and gfortran no longer working with the old binutils and glibc still present in well known "enterprise" linux distribution. gcc is a little better able to work across a range of years without matching updates.

[keithmay]

Quoting - tim18

Intel C and C++, and, to an extent, Fortran, are specifically based on the include files and run-time libraries of the most popular C++ implementation for the corresponding operating system. This lends a degree of standardization, but Microsoft makes large enough changes from time to time that there isn't very good compatibility between VC6 as it stood at the end of the CVF era and current VC9, much less VC10, which seems likely to require significant changes to ifort once again. Even VC7.1 isn't viable with many currently supported Windows versions. At the source code level, Fortran retains excellent compatibility from CVF on through the latest compilers, more so than C++ did over that time period.
Likewise, linux sees changes from time to time, with mainstream builds of g++ and gfortran no longer working with the old binutils and glibc still present in well known "enterprise" linux distribution. gcc is a little better able to work across a range of years without matching updates.

Thanks again tim18. I suppose I was wasting my time dreaming of a better world. At least I can be happy about my source code being okay. But I'm going to have to spend the next few weeks/months beating up my FORTRAN compatriots to upgrade along with me - a task that depresses me - I'd much rather be writing code.

Am I being naive here? Your response suggests that this kind of problem is just par for the course. We should just suck it up and get over it. As softwre developers we don't only write code but must alsodeal withthe whole architecture of our environment. What's up with that?

Again, don't respond to thisif you have no time/interest. But dammit, I've been writing code for 40 years and I'm spending most of my time dealing with things that have nothing to do with the "SOLUTION". Sounds like a good topic to the Journal of the ACM - I''m about ready for a rant.

Thanks again for your help tim18 - I'm signing off this this thread. If you want to continue this discussion off-line let me know how to do it.

[Steven_L_Intel1]

Your CVF DLLs will continue to work as long as you keep the CVF run-time DLL (DFORRT.DLL) on the system. You can call these from Intel Visual Fortran code as long as you don't try to share I/O units, dynamic allocation or pass assumed-shape arrays.

I know Tim was trying to be helpful, but he missed an important aspect to your question. If you had asked about static libraries, Tim's answer would be correct - you cannot mix these with Intel Visual Fortran. But DLLs you can call, with a bit of care (you need to get the calling conventions right, and IVF provides means to do that.)

If you have further questions, let me know.