Need single thread dll in fortran

[Marco_S_1]

Hi,
sorry i am a mathematician who can more or less program, so, please, forgive my low level question. I am building a 32bit dll with intel fortran 2013 from visual studio 2010 on windows.I need to call it from R ( a statistical program). which requires very simple single thread dlls (obviously no MP). At the office i have a 32bit single core processor and windows Xp and I can compile and call it OK. At home I have an i5 quadricore 64bit. on windows 7 and I don't have the single thread option in VS (so it always compiles with the /threads option). I believe this is why I get the message "#1 is not a valid win32 application" when I load a version compile at home. Can anyone suggest how i can select the single thread option from VS2010 or add a compiler directive at home?

many thanks, marco.  

[jimdempseyatthecove]

Where are you placing your DLL?

Your first experiment is to eliminate variables in cause for error. On your 32-bit machine, write a Fortran "hello world" that makes a simple call to your DLL. Test it on your 32-bit machine to make sure it works. Then on your 64-bit system, creat a new folder (not in a Windows system folder) and place your DLL and "hello world" application that calls the dell into this folder. IOW the .exe and .dll reside in the same folder and this folder is not a Windows folder. Launch a CMD session (aka "DOS" box), set current directory this test folder and run the test application.

Do you get the same error?

Jim Dempsey

[TimP]

The Visual Studio project properties menu has a selection for OpenMP.  Its effect is to set /Qopenmp which you would see in your build log. The other ways in which your Fortran could generate multiple threads are with /Qparallel (also check build log), with MKL function calls either explicit or by -opt-matmul which is implied by -O3.  If you have an MKL link it has the option of turning off threading by /Qmkl:sequential.  I would have thought that R could accept a .dll which involves threaded functions.

The threading issue is unrelated to "not a valid win32."  That could be a result of building with ifort Intel64 (64-bit compiler), resulting in a 64-bit .dll, as you would normally do for running on Win7-x64, but then attempting to run on XP32.  If you would assure that you also installed the ifort ia32 compiler and use that, along with a 32-bit Windows build of R, you could make consistent 32-bit builds which would run on both the 32- and 64-bit Windows.

ifort builds nowadays always link thread-safe libraries, as Visual Studio has dropped the single-thread libraries.  The Windows libraries in use will be MT or (for debug mode) MD.  Those libraries work with both single- and multi-thread builds.  If you have questions about your build.log (if building inside VS GUI), you could show it here, or if it's command line show us the ifort build commands.

[SergeyKostrov]

>>...At the office i have a 32bit single core processor and windows Xp and I can compile and call it OK. At home I have >>an i5 quadricore 64bit. on windows 7 and I don't have the single thread option in VS (so it always compiles with the >>/threads option). I believe this is why I get the message "#1 is not a valid win32 application"... The message is "...is not a valid win32 application" is always very confusing. It is possible that: - You're trying to use a 64-bit DLL with 32-bit application or - Some 32-bit DLL dependencies are missing You could do a very simple test with MS Depends utility to verify all dependencies of your 32-bit DLL. >>...At home I have an i5 quadricore 64bit. on windows 7 and I don't have the single thread option in VS... Do you have the same edition / version of VS at home? If both VSs, that is at home and at work, are the same then something else is wrong.

[Bernard]

Microsoft KB has some more detailed info on your problem ://support.microsoft.com/kb/812486/en

[SergeyKostrov]

During last 9 months, or so, we had at least 5 similar reports related to different Intel software products and Microsoft Visual Studios 2010 and 2012. Since your problem is related to Fortran the best advise is to look for an article created about 2 months ago by Steve Lionel. There was even a sticky post about the problem on Intel Visual Fortran forum. However, I don't see that sticky post any longer but I'm confident that if you try to search on IDZ website that article will be found.