XE2013 Integration Incomplete with VS 2008, VS2012

[garylscott1]

The newest configuration I can upgrade to at work is XE2013.  I've had difficulty with the integration of the 64-bit compiler only.  In both VS2008 and VS2012 only the 32-bit compiler is available.  The setup utility indicates that the 64-bit compiler is installed and integrated, but when I select the x64 target (I have to select "new" in the config manager), it still calls the 32bit compiler when building.  In Tools >> Options, only the 32 bit platform is selectable (both 2008 and 2012).  I used setup to foreably update (modify) the 64-bit compiler but it indicates already installed and when I go ahead and install it gives successful completion, but no change in availability in VS.  I have 2017/2015 at home with no problems.  I was going to try to manually edit the directories (for 32-bit platform since it wont let me select 64-bit) in tools >> options by copying my home configuration settings, but my home system is AMD/win10 and work is I5/win7.  Again, 32-bit is integrated and works perfectly, only 64-bit is not.  The compiler is present and I can use it from the command line.  What stupid thing am I doing wrong?

[Kevin_D_Intel]

So under Tools > Options > Intel Compiler and Tools > Visual Fortran > Compilers do you not see a specific x64 tab?

Re: Building the x64 configuration, Under Build > Configuration Manager, is the Active Solution Platform pulldown set to x64?

If you are not seeing the x64 tab under the Tools > Options, you might try the steps outlined in Troubleshooting Fortran Integration Issues with Visual Studio

[garylscott1]

Eventually integrated with VS2012 (which is not authorized and which might go away mystically at any time).  Successful build, but it is running super slow and experiencing access errors in user32.  Behaves somewhat like the wrong SDK perhaps pointed to.  Works so long as I don't position pointer in a text field for typing.  Unable to integrate into VS2008, which is the authorized install.

Linker:

/OUT:"x64\Debug\Staffview64.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"u:\gino80\GINO64" /NODEFAULTLIB:"LIBCMT" /MANIFEST /MANIFESTFILE:"U:\F95Source\Staffview64\x64\Debug\Staffview64.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"U:\F95Source\Staffview64\x64\Debug\Staffview64.pdb" /SUBSYSTEM:WINDOWS /STACK:20000000 /ENTRY:"mainCRTStartup" /IMPLIB:"U:\F95Source\Staffview64\x64\Debug\Staffview64.lib" gmwin.lib gmwinerr.lib gwogl.lib ginlibi8.lib gsurfi8.lib ggrafi8.lib gmenuwi8.lib

Compiler:

/nologo /debug:full /Od /Ob2 /Ot /I"u:\gino80\GINO64\modules" /warn:interfaces /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc110.pdb" /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /winapp /Qmkl:sequential /c

Executables:

$(IFortInstallDir)bin\Intel64
$(VSInstallDir)Common7\ide
$(VCInstallDir)bin\amd64
$(VCInstallDir)bin
$(VSInstallDir)Common7\Tools
$(VSInstallDir)Common7\Tools\bin
$(FrameworkDir)$(FrameworkVersion)
$(WindowsSdkDir)bin\x86
$(PATH)

Includes:

$(IFortInstallDir)compiler\include
$(IFortInstallDir)compiler\include\Intel64
$(IFortInstallDir)mkl\include
$(VCInstallDir)atlmfc\include
$(VCInstallDir)include
$(WindowsSdkDir)include\um
$(WindowsSdkDir)include\shared
$(FrameworkSDKDir)include

Libraries:

$(IFortInstallDir)compiler\lib\Intel64
$(IFortInstallDir)mkl\lib\Intel64
$(VCInstallDir)atlmfc\lib\amd64
$(VCInstallDir)lib\amd64
$(WindowsSdkDir)lib\win8\um\x64
 

Default Options: 

/Qvc11 /Qlocation,link,"$(VCInstallDir)\bin\amd64"

So...this is not an amd64 machines.  It is a Win7 SP1 4 core I5...however an environment variable incorrectly indicates AMD processor architecture...a clue?

[Steve_Lionel]

Windows calls x64 "AMD64" - don't worry about it.

You haven't shown us what the "USER32" errors are.

I have seen it sometimes, especially with a solution that has multiple projects, that creating the x64 solution configuration doesn't set the platform to X64 for all the projects. Go to Build > Configuration Manager and make sure that Platform is set to x64 for all the projects in the solution (once you have selected x64 as the Active Solution Platform.)

[garylscott1]

It's a newly created new single, simple project with 3 fortran files and two resource files.  All external libraries are gino and MKL as shown.  No issues with my configuration at home, I can compile the code interchangeablly as 32 or 64 bit with no obvious difference in performance or behavior (except more memory available for x64).  The user32 error is somewhat vague, just an access error and it aborts immediately with a numeric (hex I think) return code.  Home now, don't have the return code value at the moment.

[garylscott1]

It seems that the error in VS is "a problem caused <program> to stop responding". 

In the debugger, the message is "unhandled win32 exception occurred in <program> [9684]"

9684 does not appear to be a getlasterror code value that I can find.

Since this a 64 bit app, should I be getting a win32 exception message or is that just crud?

The program starts until I select the password field to enter a password.  I can comment out and bypass the password and the program will run, but very slowly, so long as I don't select any text entry fields.  Makes me think its running with the wrong OS DLLs although I've linked with the 64 bit 3rd party lib/DLLs (otherwise I would have gotten a link error) and I've copied the 64-bit 3rd party DLLs to the local directory to try to resolve the issue with no impact.

[Steve_Lionel]

"win32" is an old term for the Windows API.

Unfortunately, your description is too vague to be able to offer any useful suggestions. If you're willing to attach a ZIP of the project with sources, we can try it for ourselves. 

[garylscott1]

It is vague because that is all the info available.  I don't think it would be useful, and probably not technically legal for me to supply the 3rd party libraries.  Both 32 and 64 bit configurations work perfectly at home.  I've verified as best I can identical project and switch settings.  I tend to think it is a run-time issue with the wrong DLL set being loaded rather than a build time issue.  I will keep plodding away. 

As an aside, my attempts to fix the 64-bit integration into VS2008 appears to have irreparably damaged the 32-bit integration.  I've tried uninstall/reinstall of xe2013 (and following the command line based process pointed to earlier).  It seems likely I'll have to reinstall VS2008 and start over.  At least the 2012 integration appears to be working.  It is complicated at work because I don't have admin rights and have to work around everything.

[garylscott1]

After rummaging through old problem reports, it turns out that a 3rd party library, one particular revision level which I happen to have installed (lucky me), has an incompatibility only with the IVF 64-bit compiler.  It seems that my install is one rev tool old.  I upgraded the 32-bit but not the 64-bit libraries because I had no 64-bit apps.  It is difficult to tell the revision installed however because for incremental user-level fixes, they sometimes just email you a new LIB/DLL without changing the rev letter.  I've complained about the resulting CM problems in identifying exactly what I have installed :(  I recommended, minimally a "build x" nomenclature that always increments, but I've not seen evidence of implementation yet.

Anyway, I have an upgrade on order (pre-existing) which should resolve this soon (hopefully).

Sorry for the kerfuffle...chaff, wheat...you know...