VS 2013/Intel Fortran Compiler XE 14.0 and an OLD project

VS 2013/Intel Fortran Compiler XE 14.0 and an OLD project

Imagen de NotThatItMatters

I am trying to get an ancient (small) project to compile/link with VS 2013 and Intel(R) Visual Fortran Compiler XE 14.0.1.139 [IA-32].  The project/solution creates a DLL which is used by some VB6 code at present.  The attempt was to take the code and project as is and compile/link them to create the DLL in order to have a baseline to update the code to F90/95/2003/...  At present the link is failing with

Error 2 error LNK2001: unresolved external symbol __DllMainCRTStartup@12 C:\Users\Stephen\Documents\Fortran\GRIDDLL\LINK GRIDDLL

This is unfamiliar.  What might this mean?  What project settings may be missing?

 

publicaciones de 17 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Steve Lionel (Intel)

I'm going to guess that this isn't the only error message you're seeing. Try this - go into the project property Fortran > Libraries and make sure "Use Runtime Library" is set to "Multithread DLL". Then look at the Linker > Command Line property and make sure there's no reference to libc.lib. Do a complete rebuild of the project (not just "Build")

If this doesn't help, please attach a ZIP of the buildlog.htm from the failed build.

Steve
Imagen de NotThatItMatters

I grabbed the old project as is and converted it to new.  It would appear that it is a bit confused.  It looks as if it is partially a VC++ project and partially a Fortran project.  I do not have the Fortran page in my project.  How might I proceed?

Imagen de Steve Lionel (Intel)

Ah, it's an old CVF project. Is it that the Fortran project doesn't act like it's Fortran? Right click on the Fortran project and select "Extract Compaq Visual Fortran project items..." and follow the prompts.

Steve
Imagen de NotThatItMatters

Okay, I finally got the VC/Fortran problem handled.  Now comes a more unique bug.  I compiled the dll in the past using

Intel(R) Visual Fortran Compiler XE 13.0.1.119 [IA-32]

The dll runs properly when placed in the C:\Windows\system32 [XP] or the C:\Windows\SysWOW64 [Vista, 7, 8].  I now recompiled the almost identical code with

Intel(R) Visual Fortran Compiler XE 14.0.1.139 [IA-32]

I changed the linker version string.  I get a new dll which I put in the proper folder.  When the ancient VB6 exe runs, it complains "File not found: cont532,dll".  What has happened?  Is there a linkage or library problem?

I will try to attach the BuildLog files for the two compiles.

Imagen de NotThatItMatters

See attachments.

Adjuntos: 

AdjuntoTamaño
Descargar BuildLog.docx12.01 KB
Descargar BuildLogNew.docx12.01 KB
Imagen de IanH

The symptoms sound a bit like missing runtime libraries.  On each system that you try and load a DLL or exe that has been dynamically linked against the Fortran runtime, you need to have installed the runtime libraries for the same or later version of the Fortran compiler and the C++ runtime libraries for the version of Visual Studio that you are (effectively) using and the system needs to be able to find those DLL's when it loads your DLL or EXE.

When you install the compiler on a machine, the runtime libraries for that compiler are installed at the same time.

You can download separate installers for the Fortran runtime libraries from the same place that you download the compiler.  From memory they come in a zip file, inside which are msi's for 32 bit and 64 bit compiles.  If you already use an installer for your program there are merge modules that achieve the same thing under the redist folder of your compilers install.

For the Visual Studio related C++ runtimes you will find a vcredist.exe downloadable from the Microsoft website that you can use to install the relevant runtime on client machines.  There are also merge modules that the VS install places in the common files area that can do the same thing.

For both ifort and VC runtimes another option is to actually copy the individual runtime DLL's to the target machine.  But you need to be mindful about the rules around how DLL's are then located (they may need to be on path if the thing that you are deploying is a DLL).

You will find more information under the fortran compiler help topic "Redistributing Libraries When Deploying Applications".

Please don't plan on putting your DLL's or the ifort runtime DLL's into the system folders, or one day you will find yourself running away from a heap of your users armed with pitch-forks.

Imagen de Steve Lionel (Intel)

Does it really say "cont532,dll", with a comma in the file name?

Steve
Imagen de NotThatItMatters

No, the comma in the file name was me.  Sorry.

I finally got the dern thing to run by loading two redistributables and msvcr120.dll into the relevant machine.  This was a "test of concept" exercise, to make sure the current code works.  I have been struggling mightily ever since my Intel Fortran machine went belly-up and we found no other machine with the software.  After numerous days of downloading, running, wiping, re-downloading, ... we finally have something resembling a machine that works with ALL our Fortran executables, both dll's and exe's.

And, no, this is NOT how this software gets distributed.  InstallShield loads all the relevant dll's in their proper places for use.

Imagen de NotThatItMatters

I am having one other "problem" with the dll's created in this process.  I am noting that when running Dependency Walker on the dll's in question, I often get the problem that the linked redistributable dll's LIBIFCOREMD.DLL and LIBMMD.DLL are x64 when I am building for Win32.  Why is this?

Imagen de Steve Lionel (Intel)

Dependency Walker doesn't follow WIndows' rule for skipping x64 DLLs when searching PATH for 32-bit DLLs on a 64-bit system. This has always been an annoyance to me. Even the x64 version doesn't do this.

Steve
Imagen de NotThatItMatters

The problem here has escalated a little, not with the dll's, which we finally got running on the old Win32 XP machine by loading in the appropriate redistributable libraries, but instead with the "big exe".  Dependency Walker on a Win32 compiled exe yields "no" trouble with the exe.  But the exe itself, when "run" on the Win32 XP machine complains "This is not a Win32 exe".

I have attached two results from dumpbin /headers, one on the compiler machine (summary_new) and one from the XP machine (summary).  Also attached is the Fortran project file.  The compiler machine is Windows 7 Professional SP1 64-bit and the exe runs here.  It also seems to run on every 64-bit machine I have tried.  A previous compiler machine (which has crashed) which produced workable Win32 exes was Windows Vista Professional SP2 64-bit.

Adjuntos: 

Imagen de Steve Lionel (Intel)
Best Reply
Steve
Imagen de NotThatItMatters

Thank you for the input.  I followed the directions in the link but I am still getting the error.  I made the assumption that VS 2013 would have the updates associated with VS 2012 SP1.  Attached is my updated project file:

Adjuntos: 

AdjuntoTamaño
Descargar MerSim_0.vfproj9.83 KB
Imagen de Steve Lionel (Intel)

Well, this project doesn't show that you did any of the things recommended in the article. I also notice you have an extremely large stack reserve size set - this can also cause similar errors. I recommend not going over 200MB for stack reserve size. Use Optimization > Heap Arrays > 0 if you're getting stack overflows.

Steve
Imagen de NotThatItMatters

Steve, thanks for the link.  Despite my last posted files, I had made the attempt to implement the SUBSYSTEM:Windows="5.01" but somehow failed.  I need to learn this IDE.  Anyway, the exe compiles and runs now on all the OS's we are using.

Thank you.

Imagen de Steve Lionel (Intel)

Glad to hear it!

Steve

Inicie sesión para dejar un comentario.