IMSL and going from visual studio 2012 to 2010

[Brian_Murphy]

I have ported a working project from one computer with visual studio 2012 to another with visual studio 2010, and I'm getting a strange error from a routine named LSAME during an IMSL operation that is computing a matrix solution using overloaded operators and Harwell sparse matrices.  It looks like RESULT = A .ix. RHS.  I think the problem is in the porting, not the program.  Is there anything I should have done while porting to make it work?

I think the VS2012 system has visual fortran composer XE 2013 update 5, and the VS2010 system has update 4.  Could that be my problem?

[Brian_Murphy]

I have compared the command lines for compiling and linking between the two systems. 

The linking's are identical. 

/OUT:"Debug/XLTRC2.exe" /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:"libc" /NODEFAULTLIB:"Libcmtd" /MANIFEST /MANIFESTFILE:"C:\TRC-2013\Lateral Torsion Coupling\XLTRC2\Debug\XLTRC2.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Debug/XLTRC2.pdb" /MAP /SUBSYSTEM:CONSOLE /STACK:500000000 /IMPLIB:"C:\TRC-2013\Lateral Torsion Coupling\XLTRC2\Debug\XLTRC2.lib"

The compiling's are identical except for two things.  The five /I pieces are in the order shown below for vs2012, but in vs2010 they are in reverse order.  Also, vc110.pdb in vs2012 becomes vc100.pdb in vs2010.  I remember now that for two C language elements of the project, I had to change something called "Platform Toolset" from v110 to v100 on the vs2010 system. 

/nologo /debug:full /Od /I"Debug/" 
/I"C:\TRC-2013\Lateral Torsion Coupling\DLLUser\Debug/" 
/I"C:\TRC-2013\Lateral Torsion Coupling\ARPACK\LAPACK\Debug" 
/I"C:\TRC-2013\Lateral Torsion Coupling\ARPACK\BLAS\Debug" 
/I"C:\TRC-2013\Lateral Torsion Coupling\ARPACK\UTIL\Debug" 
/I"C:\TRC-2013\Lateral Torsion Coupling\ARPACK\SRC\Debug" 
/DXLTRC_INTEL_VF /DDEBUG_MODE_UCS /assume:nocc_omp /Qopenmp /module:"Debug/" /object:"Debug/" /Fd"Debug\vc110.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:output_conversion /check:stack /libs:dll /threads /dbglibs /c

[Brian_Murphy]

I also had to copy a file named msvcr110d.DLL to the system with vs2010.  If I try to run the code without this file, I get a windows messagebox saying the code can't start because that file is missing.  I've got no idea why the code wants this file.  I have rebuilt everything in the project on the vs2010 system (to the best of my knowledge).  I've done a right click on the top level item in the Solution Explorer and selected Clean solution, followed by a rebuild.

I will try the things you suggested later this afternoon.

[Steven_L_Intel1]

That's the debug DLL MSVC run-time library from VS2012. You should always build Release configurations when copying between systems. You still have something (maybe another DLL?) built with VS2012.

I'd still like to see a build log showing the compile commands.

[Brian_Murphy]

The full rebuild is attached.  This was built just after a complete clean of the entire solution.

What exactly do you mean by "build Release configurations when copying between systems".  I need to build both Release and Debug.  I copied the source, copied the vs project files, and edited the version number in the .sln with a text editor so I could open it with vs2010.

At this point, both systems ought to have the same versions of the intel compiler and imsl.  They are both Windows 7.  One has vs2012 and one has vs2010.

[Steven_L_Intel1]

Right. Your debug build creates dependencies on the MSVC debug DLLs for the VS version you used. You're evidently NOT rebuilding everything. Debug DLLs are not redistributable (includes copying between systems.)

Your build log shows you are linking against several libraries and objects you didn't build locally.

[Brian_Murphy]

Good news!  link_fnl_shared.h got the program running to completion, and it's no longer calling the LSAME in my lapack during IMSL's use of the .ix. operator.  However, I've got work to do to determine if it's actually running correctly.

I went to https://registrationcenter.intel.com/en/products/ to order a subscription renewal, but the link for How can I buy or renew? was a dead end (it went to page for downloading trial software).  Can you point me in the right direction?

[Steven_L_Intel1]

Glad to hear it.

You are supposed to be able to buy a renewal through the Intel Software Manager. You can buy from us directly by going to https://software.intel.com/en-us/intel-parallel-studio-xe/try-buy#buynow and pick the link for the product you want. Note that there are separate options for pre-expiry renewal and post-expiry renewal. See https://software.intel.com/en-us/articles/renewal-period-start for more details.

[Brian_Murphy]

I always get the same thing from the Intel Software Manager; Cannot connect to update server.  Clicking Refresh doesn't help.  This would be the easiest option for me if I could just get it to work.  I poked around those links you provided, but didn't get very far.  I think I will have to call Intel at 1-800-599-4285.  I'm not sure how that will work because I am deaf.

[Steven_L_Intel1]

You could also buy from a reseller. See a list at https://software.intel.com/en-us/intel-software-products-resellers/

[Brian_Murphy]

Steve - can you please elaborate on why the change from static to shared on the imsl thing cured my problem.  Will using this as a permanent fix be asking for trouble down the road?

[Steven_L_Intel1]

The change caused IMSL to rely entirely on its internal routines, ignoring any of your routines that had the same name - LSAME in this case. It could be that IMSL's internal LSAME assumed different calling conventions from the one you had, though a brief look at this didn't tell me this was so.

[vishal_p_]

The LSAME versions in IMSL, MKL,etc., were probably compiled with optimization set on and argument checking turned off.

If, however, LSAME is compiled from Fortran source and argument checking was turned on during that step, the otherwise harmless mismatch would cause the program to abort.

[Steven_L_Intel1]

I'm going to guess that the call to LSAME from IMSL was done with actual arguments that weren't character, so lengths weren't passed. Indeed IMSL gets built without runtime checks, but if the call to LSAME had indeed passed a character value it should have been ok. There are MANY calls to LSAME in IMSL and I'm not going to try to check all of them.

[Brian_Murphy]

I received an email notification that mecej4 posted to this thread, but his post is not appearing in the online forum.

It's still a mystery to me why the code runs differently on a computer with vs2012 than with vs2010.  The fortran and imsl versions are the same as far as I can tell.  Only visual studio is different.

But I can't spend any more time worrying about it right now.  Thank goodness (and Steve L.) I've finally got it running, and I can move on to the things I need to be doing.