Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

using CVF obj files with IVF: dfor.lib problem

Wayne_L_
Beginner
791 Views

The use of object files compiled with Compaq Visual Fortran often yields a dfor.lib error.  While the IVF software has a "help" capability - it recommends that one recompile the CVF object 'without explicit reference to dfor.lib' (not helpful, since I cannot do that).

The IVF composer Help utility was not helpful, and a www search led to this site- which also had only cryptic replies, none of which could be implemented.  (we don't own the CVF source code, merely the object file)

The simpler answer is to obtain a CVF Library and add in the IVF-requested *.libs one at a time [In our cases, several 'missing library file' errors arose after dfor.lib was provided.], until the CVF Library Call error message (#  ) disappears.  You then get a _long list_ of errors, all of which reveal a conflict between existing IVF library files and the new CVF ones.  Don't be discouraged by the large number of errors!  Just add each IVF Library DLL to the "ignore specific file" list, again one at a time. 

This will enable IVF source code to link to CVF-compiled Objects.

0 Kudos
8 Replies
andrew_4619
Honored Contributor II
791 Views

You cannot use the CVF-built library with Intel Fortran - you must get a library that was built with Intel Visual Fortran.

0 Kudos
Wayne_L_
Beginner
791 Views

I can and I did and it works just fine.  Has anyone at Intel even attempted the guidance I provided?

As such, I'd like to update my profile to reflect "advanced" skills, since I've been coding in Fortran since 1977.

Perhaps Intel is engaged in some form of monopolistic practices?  We have NO viable option but to use the CVF object file as-is.

0 Kudos
Steve_Lionel
Honored Contributor III
791 Views

No, your suggested solution does not in fact work. While you may be able to get it to link, the CVF and Intel Fortran libraries have many routines of the same name but that operate differently internally. If your CVF code is VERY simple, you might get away with it, but in the more common case the program will fail at runtime with any of a wide variety of errors.

What you have done is NOT "advanced" - it is the equivalent of the driver who pulls around railroad crossing gates and hopes to not get hit by the oncoming train. It's simply bad advice.

Code compiled by different Fortran compilers can't be mixed; you have to recompile all the code. Sometimes you can get away with linking the code from one compiler into a DLL and having that compiler's run-time DLLs available, but even then you can run into issues with calling between the different implementations.

0 Kudos
Wayne_L_
Beginner
791 Views

Perhaps we have the situation backward... the code compiled into a CVF object is very complex, probably 50000-100000 lines of code and many mathematical operations, specialized convergence routines, etc.  The Fortran "main" routine is simple - basically allows us to insert "customer" curves/arrays and adjust WRITE statements, to get a few of the hundreds of variables out in an analytically useful format.  The Fortran code thus makes few/no calls to any of the IVF Libraries, at least none of those used by the Proprietary CVF object.

As such, my method follows the _directions given by the compiler error messages_, by using required CVF Libraries and eliminating the conflicting IVF Library files.

Suggesting that "we must recompile the CVF source" due to somebody else's potential problems is equivalent to telling me to grossly abuse your tax dollars.  Its just not at all practical.

... there is no train crossing... no risk at all, just misdirection.  It worked on several model codes. 

Just wanted to point out that your advice merely added to the confusion.

I suppose that were we needing to add complex new math capability to the Fortran part of the model there might be a conflict.  But that is never going to happen!  We need to maintain the model for future young engineers to work with.

I will now tell my colleagues that we did what Intel considers impossible.

I do appreciate your insight... but it overlooks a very real situation.

0 Kudos
Steve_Lionel
Honored Contributor III
791 Views

As such, my method follows the _directions given by the compiler error messages_, by using required CVF Libraries and eliminating the conflicting IVF Library files.

When I was in college I served as a teaching assistant for an undergrad programming class that used PL/C, an "error correcting" version of PL/I. Given a syntax error, the compiler would try to rewrite the statement in a valid form, saying "PL/C uses...". In some cases it could make a reasonable guess, but most of the time, while the rewritten statement was syntactically valid, it didn't do what the programmer wanted. (If the compiler couldn't even do that, it would simply eliminate the statement!) I had many students come to me having rewritten their program because "the compiler told me to do this..." without determining if the compiler's suggestion was in fact correct for their application.

Error messages are there to alert you to a problem - rarely do they accurately instruct you as to how to solve the problem. It is true that the Microsoft linker (which is what is giving the messages you see, not the Intel compiler) often suggests options (such as using /IGNORELIBRARY), but my experience is that these usually paper over the real problem or make things worse (hence my analogy to the railroad crossing.) In my experience, users who take this type of approach often get themselves into deeper trouble later. (An example is using an ALIAS directive to hide calling mechanism mismatches.)

If your description is correct in that the main program is just a jacket for your CVF code, then sure, you probably have a good chance of making this work. You didn't mention this in your original post. It isn't the general case, however, so your situation doesn't really help most people who are trying to integrate old compiled code into a new application and I recommend against others following your instructions.

P.S. I no longer represent Intel

0 Kudos
Kevin_D_Intel
Employee
791 Views

It seems in a number of cases there is no solution for mixing the objects. There are other posts discussing possibilities of mixing CVF and IVF compiled code that may be usable in other cases (i.e. separate DLLs), and as mentioned in earlier replies in this post. Thank you for sharing the details and prescription that worked for your case.

0 Kudos
andrew_4619
Honored Contributor II
791 Views

Well it seems to me that you have a 'solution' to your current problem and have made an exe than runs (and presumably gives what look like sensible answers). Your real problem is you are reliant on a library built in a compiler that was obsolete 15 years ago that you have no source for and it would appear that it is no longer supported by it's creators ( I assume this as you say getting an update is not possible). If you have a long term need for the functionality of this software I think you need to work on a plan B! 

0 Kudos
Wayne_L_
Beginner
791 Views

Yes, Steve, the CVF object file contains most of the Proprietary logic.  The Main code primary allows us, the customer, to adjust inputs and format output.

I do not know what situation most people are in when attempting to recompile older code, but we need to keep the model working as long as possible, since it is costly and very time-consuming to pay for another *.obj version just to have it compiled in a compatible compiler.

As such, I though it would be worthwhile to advise folks that it is not always necessary to obtain and recompile the Object file code to get it to run compatibly with Fortran source code compiled with Intel 13.  That is, selectively Including requested Compaq Library files, as indicated by the (Linker) and then late selectively Ignoring Intel Library files, also as indicated by error messages, worked in this situation.

 

 

In fact, in one case, I found that I couldn't include the Intel Fortran Libraries in the executable, but had to have them locally available during run-time.  In that one case, I went ahead and produced a data-dump for future analysts. 

0 Kudos
Reply