cannot open file 'ifconsol.lib'

Accedi per lasciare commenti

Steve Lionel (Intel)

Mer, 19/03/2008 - 14:34

Is this an all-Fortran project or is there C/C++ code? Can you post the buildlog.htm contents?

Steve

Accedi per lasciare commenti

barakobama

Mer, 19/03/2008 - 14:49

It's a mixed soln with C and Fortran.

Here is the log start and end with some of the middlelog deleted.

1>------ Rebuild All started: Project: tg230_lib, Configuration: Debug Win32 ------
1>Deleting intermediate files and output files for project 'tg230_lib', configuration 'Debug|Win32'.
1>Compiling with Intel Fortran 9.1 C:Program Files (x86)IntelCompilerFortran9.1IA32...
1>tascflow ascflw9.f
1>projectpspher.f
1>partsstarseq.f
1>partsextrude.f
1>parseadmicr.f
1>outputotopaz3d.f
1>output
eutral.f
1>outputennike3d.f
1>options zopts.f
1>optionsdnopts.f
1>mergelocate.f
1>irisguispecfnc.f
1>C: gsrc.230irisguispecfnc.f(1436) : Warning: The data type of the actual argument does not match the definition. [1]
1>irisguimenustrg.f
1>C: gsrc.230irisguimenustrg.f(94) : Warning: The data type of the actual argument does not match the definition. [1]
1>irisguiguips.f
1>C: gsrc.230irisguiguips.f(181) : Warning: The data type of the actual argument does not match the definition. [1]
1>irisguiGlonlymovesrc.f
1>irisguidwbttn.f
1>.includedeflgop.h(31) : Info: This statement function has not been used. [JSHIFTR]
1>.includedeflgop.h(41) : Info: This statement function has not been used. [JSHIFTL]
1>.includedeflgop.h(31) : Info: This statement function has not been used. [JSHIFTR]
1>.includedeflgop.h(41) : Info: This statement function has not been used. [JSHIFTL]
1>.includedeflgop.h(31) : Info: This statement function has not been used. [JSHIFTR]
1>.includedeflgop.h(41) : Info: This statement function has not been used. [JSHIFTL]
1>.includedeflgop.h(31) : Info: This statement function has not been used. [JSHIFTR]
1>.includedeflgop.h(41) : Info: This statement function has not been used. [JSHIFTL]
1>.includedeflgop.h(21) : Info: This statement function has not been used. [JOR]
1>.includedeflgop.h(31) : Info: This statement function has not been used. [JSHIFTR]
1>.includedeflgop.h(41) : Info: This statement function has not been used. [JSHIFTL]
1>.includedeflgop.h(21) : Info: This statement function has not been used. [JOR]
1>.includedeflgop.h(31) : Info: This statement function has not been used. [JSHIFTR]
1>.includedeflgop.h(41) : Info: This statement function has not been used. [JSHIFTL]
1>.includedeflgop.h(21) : Info: This statement function has not been used. [JOR]
1>.includedeflgop.h(31) : Info: This statement function has not been used. [JSHIFTR]
1>.includedeflgop.h(41) : Info: This statement function has not been used. [JSHIFTL]
1>.includedeflgop.h(21) : Info: This statement function has not been used. [JOR]
1>.includedeflgop.h(31) : Info: This statement function has not been used. [JSHIFTR]
1>.includedeflgop.h(41) : Info: This statement function has not been used. [JSHIFTL]
1>C: gsrc.230irisguidwbttn.f(638) : Warning: The data type of the actual argument does not match the definition. [1]
1>interpolxcurves.f

1>interpolmesh.f
1>inputindyna3d.f

........

DELETED: because it's too long.

.......

2>c: gsrc.230secure3setmcc.c(323) : warning C4305: 'function' : truncation from 'double' to 'float'
2>c: gsrc.230secure3setmcc.c(757) : warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
2> c:program files (x86)microsoft visual studio 8vcincludestring.h(157) : see declaration of 'strncpy'
2>c: gsrc.230secure3setmcc.c(758) : warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
2> c:program files (x86)microsoft visual studio 8vcincludestring.h(157) : see declaration of 'strncpy'
2>c: gsrc.230secure3setmcc.c(771) : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
2> c:program files (x86)microsoft visual studio 8vcincludestring.h(74) : see declaration of 'strcpy'
2>c: gsrc.230secure3setmcc.c(781) : warning C4101: 'l' : unreferenced local variable
2>c: gsrc.230secure3setmcc.c(780) : warning C4101: 'j' : unreferenced local variable
2>Generating Code...
2>Compiling resources...
2>Compiling manifest to resources...
2>Linking...
2>LINK : fatal error LNK1104: cannot open file 'ifconsol.lib'
2>Build log was saved at "file://c: gsrc.230DEBUGBuildLog.htm"
2>tg230 - 1 error(s), 923 warning(s)
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped =========

Accedi per lasciare commenti

Steve Lionel (Intel)

Mer, 19/03/2008 - 15:01

I thought so.

In Visual Studio, go to Tools > Options > Projects > VC++ Directories. For "Library Files", add the full path to the Intel Fortran "Lib" folder.

Steve

Accedi per lasciare commenti

barakobama

Mer, 19/03/2008 - 16:20

Thanks.

It solved the problem and I successfully made the 32 bit version

on Xeon.

Now, I am trying to make a 64bit version and got the link error:

2>tg230_lib.lib(dialog1.obj) : error LNK2001: unresolved external symbol _for_write_seq_fmt.

I checked the forum in the past and set:

Disable Default Library Search Rules: No

for my Debug Configuration.

FYI: I set the environment as below for the 64 bit version:

Fortran side:
Set Target Platform: x64 which also set Slected Compiler
as Intel Fortran 9.1 [IA32_EM64T] automatically.

Library directory is set as

C:Program Files (x86)IntelCompilerFortran9.1em64tLib

VC++ side:
VC Projects and Solutions:
VC++ directories:
Platforms: x64
It's done in "Options" under "Tools".

Accedi per lasciare commenti

Steve Lionel (Intel)

Mer, 19/03/2008 - 16:41

You're using VS2005, yes? You need to create an "x64" configuration. This is explained in the "Building Applications" section of the on-disk documentation. You're compiling using the 32-bit compiler.

Steve

Accedi per lasciare commenti

barakobama

Mer, 19/03/2008 - 18:03

I followed the step to setup 64-bit version as you suggested.

Now, I got the error:

1>------ Build started: Project: tg230, Configuration: Debug x64 ------
1>Linking...
1>LINK : fatal error LNK1104: cannot open file 'ifconsol.lib'
1>Build log was saved at "file://c: gsrc.230x64DebugBuildLog.htm"
1>tg230 - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

I put the following path into the VC++ directories:

C:Program Files (x86)IntelCompilerFortran9.1em64tLib

which is for 64bit.

Related to this, there is a strange behavior in the Options Dialog.

In VC++ Directories of "Porjects and Solutions" node under "Tools",
I can not set the Platform x64 from Win32. It stays Win32 when I get back and open the Option dialog even though I set it to x64 and clicked OK.

-BO

Accedi per lasciare commenti

Steve Lionel (Intel)

Mer, 19/03/2008 - 21:40

Which edition of VS2005 do you have? If it is anything but the Standard Edition, you need to do a "Change" on it in Add/Remove programs to add the Visual C++ > x64 Compiler and Tools option, as it is not installed by default.

Once you have done so, you'll find that the directory lists are different for "Win32" and "x64". Make sure you select the right platform when updating the lists.

Steve

Accedi per lasciare commenti

barakobama

Gio, 20/03/2008 - 11:58

I'm using VS2005 Standard Edition.

So, I have seperate directories for 32 and 64.

Thanks to your help, I do not have the link error for "ifconsol.lib" any more. When I switchtheplatform to x64,I see the directory lists have been changed. However, I can make it stay as x64. When I revisit the Option for VC++ Directories,platform is still Win32.

Any idea?

-BO

Accedi per lasciare commenti

barakobama

Gio, 20/03/2008 - 15:01

I found a way to set x64 for VC++ directories.

I set up the environment using command prompt and then fire up

vs2005 from the prompt window.

Start menu->Visual Studio Tools->x64 Win64 Command prompt
C:Program Files (x86)Microsoft Visual Studio 8VC
"C:Program Files (x86)Microsoft Visual Studio 8Common7IDEdevenv.exe" /useenv

If I use this method, the list will not change whether it's Win32 or x64.

It shows the ones only for x64.

But I would like to understand why I can not set x64 if I do not use the 64 env prompt.

******Another question:

Some of my routinesare using 3rd party library which does not have 64bit version and got errors because of it. Is there a way of specifying the library(i.e.use this 32bit library)to use only for a specific routine while others remain 64bit?

Accedi per lasciare commenti

Steve Lionel (Intel)

Gio, 20/03/2008 - 17:38

You do not need to use the command prompt. When you want to build a 64-bit application, you must add an "x64" target configuration to your project. The instructions for doing this are in the documentation.

You cannot mix 32-bit and 64-bit code in an application.

Steve

Accedi per lasciare commenti

barakobama

Lun, 24/03/2008 - 18:24

Thanks to your help, I sucessfully built the 32 and 64 bit versions.

Now I am trying to build release version starting from 32bit.

I am gettting some unresolved external link errors, i.e. "strlen()", "sprintf()", "printf()" etc. though

it has the proper and in the files.But the same code is working for debugging version.

Could you tell me if there are any major differences in setttingsbetween debugging and release version. I am using mixed Fortran and C?

-BO

Accedi per lasciare commenti

Igor Levicki

Mar, 25/03/2008 - 00:35

It probably means that your C libraries somehow get ignored by the linker. Check your build log, project settings, especially if /Zl option is perhaps active. To me it seems like your installation of development toolchain is messed up. I would uninstall everything if I were you and start from scratch.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

Accedi per lasciare commenti

Steve Lionel (Intel)

Mar, 25/03/2008 - 06:26

In addition to what Igor mentions, I'd guess that in your attempt to solve the problem earlier you made some incorrect changes to your project. You do need to make sure that the C and Fortran projects use the SAME libraries setting, such as "multithreaded", and that you didn't start adding "ignore libraries" settings on the linker property page.

I don't think an uninstall is warranted yet - you can probably fix things with the proper settings.

Can you post a build log showing the ifort command line, cl command line and link command line?

Steve

Accedi per lasciare commenti

Igor Levicki

Mar, 25/03/2008 - 13:20

Let me clarify what I meant when I suggested reinstall above — Steve is absolutely right, there is a chance to fix it with proper settings and that should be attempted first. But for someone not familiar with setting up those things reinstall might end up being an easier way out of the "mess".

Recreating the solution/project files and making sure that you set all 4 configurations properly (Win32|Debug, Win32|Release, x64|Debug, and x64|Release), would also be among the things I would try before the reinstall.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

Accedi per lasciare commenti

barakobama

Mar, 25/03/2008 - 13:32

I like to have a fresh start since I feel I messed it up.

But before doing it, I'd like to know what went wrong and get some clues so that I do not make same mistakes again.

Here are my setups for debug and release for 32bit.

===============Release=====================
C/C++ cmd:

/I ".include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "WOGL" /D "RAINBOW" /D "WIN" /D "_VC80_UPGRADE=0x0600" /D "_MBCS" /FD /EHsc /MT /Fp".Release/mtg230.pch" /Fo".Release/" /Fd".Release/" /W3 /nologo /c /TP /errorReport:prompt

Fortran cmd:

/nologo /include:".include" /include:".include3" /include:".secure3" /define:WIN /define:WOGL /f77rtl /intconstant /iface:cref /module:"$(INTDIR)/" /object:"$(INTDIR)/" /traceback /libs:static /threads /winapp /c

Linker cmd:

/OUT:"C:myapp/mtg.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:myapp" /LIBPATH:"C:myapp
etcdf-3.5.0.win32binlib" /LIBPATH:"C:Program FilesMicrosoft Visual StudioDF98Lib" /LIBPATH:"C:Program FilesMicrosoft Visual StudioVC98Lib" /LIBPATH:"C:Program FilesIntelCompilerFortran9.1IA32lib" /MANIFEST /MANIFESTFILE:".Releasemtg.exe.intermediate.manifest" /NODEFAULTLIB:"libcmt.lib" /SUBSYSTEM:CONSOLE /MACHINE:X86 /ERRORREPORT:PROMPT version.lib wsock32.lib spromeps.lib winmm.lib netapi32.lib odbc32.lib odbccp32.lib opengl32.lib glu32.lib netcdfs.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib "..myappmtg230_lib.lib"

===============Debug=====================
Fortran cmd:

/nologo /Zi /Od /include:".include" /include:".include3" /include:".secure3" /define:WIN /define:WOGL /f77rtl /intconstant /module:"$(INTDIR)/" /object:"$(INTDIR)/" /traceback /libs:static /threads /dbglibs /winapp /c

C/C++ cmd:

/Od /I "C:mtgsrc.230include" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "WOGL" /D "RAINBOW" /D "WIN" /D "_VC80_UPGRADE=0x0600" /D "_MBCS" /Gm /EHsc /RTC1 /MTd /Fp".DEBUG/mtg230.pch" /Fo".DEBUG/" /Fd".DEBUG/" /W3 /nologo /c /ZI /TP /errorReport:prompt

Linker cmd:

/OUT:".debug/mtg230-debug.exe" /INCREMENTAL /NOLOGO /LIBPATH:"C:myapp" /LIBPATH:"C:myapp
etcdf-3.5.0.win32binlib" /LIBPATH:"C:mtgsrc.230" /LIBPATH:"C:Program FilesIntelCompilerFortran9.1IA32lib" /MANIFEST /MANIFESTFILE:".DEBUGmtg230-debug.exe.intermediate.manifest" /NODEFAULTLIB:"libcmt.lib" /NODEFAULTLIB:"libc.lib" /DEBUG /PDB:".debug/mtg230-debug.pdb" /MAP:".debugmtg230-debug.map" /SUBSYSTEM:CONSOLE /MACHINE:X86 /ERRORREPORT:PROMPT version.lib wsock32.lib spromeps.lib winmm.lib netapi32.lib opengl32.lib glu32.lib netcdfs.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib "..myappmtg230_lib.lib"

Accedi per lasciare commenti

Steve Lionel (Intel)

Mar, 25/03/2008 - 13:49

I see one problem that may or may not give you trouble - you have CVF folders in the library paths.

In VS, go to Tools > Options > Intel Fortran > Directories. In each of the Executable, Library and Include file settings, delete any entries including "DF98" in the path. Do the same for Tools > Options > Projects > VC++ Directories.

I would also advise removing the DF98 paths from the PATH, LIB and INCLUDE system environment variables (which is how they ended up in the VS paths)

Steve

Accedi per lasciare commenti

Igor Levicki

Mar, 25/03/2008 - 17:02

Steve, and what about:

/NODEFAULTLIB:"libcmt.lib"

And:

/NODEFAULTLIB:"libc.lib"

Should that be included in the project settings or not? No wonder strlen(), sprintf() and such are unresolved.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

Accedi per lasciare commenti

Steve Lionel (Intel)

Mer, 26/03/2008 - 09:31

Quite right - those should be removed. My view is that /nodefaultlib is a last-resort thing when you cannot find an alternate solution. The problem is that the linker suggests it in error messages caused by inconsistent library settings.

Steve

Accedi per lasciare commenti

barakobama

Mer, 26/03/2008 - 16:31

It worked but partially.

I removed libcmt.lib from the "ignore lib" option. Success!!

However, it appears I still need that library when I move the solution file

to another machine and ran it. What could make the difference?

System environment?

1>------ Build started: Project: mtg230, Configuration: Release x64 ------
1>Linking...
1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: malloc already defined in LIBCMT.lib(malloc.obj)
1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: _heap_alloc already defined in LIBCMT.lib(malloc.obj)
1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: calloc already defined in LIBCMT.lib(calloc.obj)
1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: realloc already defined in LIBCMT.lib(realloc.obj)
1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: _recalloc already defined in LIBCMT.lib(realloc.obj)
1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: free already defined in LIBCMT.lib(free.obj)
1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: _msize already defined in LIBCMT.lib(msize.obj)
1>LIBCMTD.lib(dbghook.obj) : error LNK2005: __crt_debugger_hook already defined in LIBCMT.lib(dbghook.obj)
1>LIBCMTD.lib(isctype.obj) : error LNK2005: _isctype_l already defined in LIBCMT.lib(isctype.obj)
1>LIBCMTD.lib(isctype.obj) : error LNK2005: _isctype already defined in LIBCMT.lib(isctype.obj)
1> Creating library C:myapp/mtg64.lib and object C:myapp/mtg64.exp
1>LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library
1>C:myapp/mtg64.exe : fatal error LNK1169: one or more multiply defined symbols found
1>Build log was saved at "file://c:myapp.230.64bitx64ReleaseBuildLog.htm"
1>mtg230 - 11 error(s), 1 warning(s)
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
N

Accedi per lasciare commenti

Steve Lionel (Intel)

Mer, 26/03/2008 - 17:04

You have a mix of debug libraries and non-debug libraries.between the C and Fortran projects. These must be the same.

Steve

Accedi per lasciare commenti

Igor Levicki

Mer, 26/03/2008 - 17:11

What you are seeing is a classic library conflict between libraries compiled using different C/C++ runtime library settings.

If you have abc.lib and def.lib both of them have to be compiled using same settings you either use /MT in all of your projects or you use /MTd in all your projects. You never mix and match debug and release libraries.

In order to solve your problem and learn from it you need to gain some basic knowledge about proper static linking.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

Accedi per lasciare commenti

barakobama

Mar, 01/04/2008 - 13:14

I think I made a 64bit version but it does seem tobehave as64bit.
It does not process 64bit int such as "myint=3000000000" which is greater than 2^31.
as I can see it from the printed value.

print*,' myint=',myint
myint= -1294967296

It is still 32bit: myint=2000000000 is fine.

Could you tell me what went wrong?
I am using XP pro 64bit ed. with Xeon (EM64T).

Appended are Settings and TOOL>Options.

Fortran:
/nologo /include:".include" /include:".include3" /include:"

.secure3" /define:WIN /define:WOGL

/f77rtl /intconstant /module:"$(INTDIR)/" /object:"$(INTDIR)/" /traceback /libs:static /threads /winapp /c

C/C++:
/I "C:myapp.230-VS2005include" /I "C:myapp.230-VS2005include3" /I "C:myapp.230-VS2005secure2" /I "C:myapp.230-VS2005secure3" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "WOGL" /D "WIN" /D "_VC80_UPGRADE=0x0600" /D "_MBCS" /FD /EHsc /MT /Fo"x64Release" /Fd"x64Release" /W3 /nologo /c /TP /errorReport:prompt

Linker:
/OUT:"C:myapp.230-VS2005x64Release/myapp64.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:mydir" /LIBPATH:"C:myapp.230-VS2005netcdfx64
elease" /LIBPATH:"C:Program Files (x86)IntelCompilerFortran9.1em64tLib" /MANIFEST /MANIFESTFILE:"x64Releasemyapp64.exe.intermediate.manifest" /SUBSYSTEM:CONSOLE /MACHINE:X64 /ERRORREPORT:PROMPT version.lib wsock32.lib spromeps.lib winmm.lib netapi32.lib odbc32.lib odbccp32.lib opengl32.lib glu32.lib netcdf.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib ".x64
eleasemyapp230_lib.lib"

Here are the lists under TOOL>OPTIONS

Executables:
$(IFortInstallDir)Bin
C:Program Files (x86)Common FilesIntelShared FilesIa32Bin
$(VCInstallDir)binx86_amd64
$(VCInstallDir)PlatformSDKin
$(VSInstallDir)Common7Toolsin
$(VSInstallDir)Common7 ools
$(VSInstallDir)Common7ide
$(FrameworkSDKDir)bin
$(FrameworkSDKDir)libwin64
$(FrameworkDir)$(FrameworkVersion)
C:Program Files (x86)Microsoft Visual Studio 8Common7IDE
C:Program Files (x86)Microsoft Visual Studio 8VCBIN
C:Program Files (x86)Microsoft Visual Studio 8Common7Tools
C:Program Files (x86)Microsoft Visual Studio 8Common7Toolsin
C:Program Files (x86)Microsoft Visual Studio 8VCPlatformSDKin
C:Program Files (x86)Microsoft Visual Studio 8SDKv2.0in
C:WINDOWSMicrosoft.NETFrameworkv2.0.50727
C:Program Files (x86)Microsoft Visual Studio 8VCVCPackages
C:WINDOWSsystem32
C:WINDOWS
C:WINDOWSSystem32Wbem
c:Program Files (x86)Vimvim70
C:Program Files (x86)Util
C:Program Files (x86)Microsoft SQL Server90Toolsinn

Libraries:
$(IFortInstallDir)Lib
$(VCInstallDir)libamd64
$(VCInstallDir)atlmfclibamd64
$(VCInstallDir)PlatformSDKlibamd64
$(VSInstallDir)SDKv2.0libamd64
C:Program Files (x86)Microsoft Visual Studio 8VCATLMFCLIB
C:Program Files (x86)Microsoft Visual Studio 8VCLIB
C:Program Files (x86)Microsoft Visual Studio 8VCPlatformSDKlib
C:Program Files (x86)Microsoft Visual Studio 8SDKv2.0lib

Include:
$(IFortInstallDir)Include
$(VCInstallDir)include
$(VCInstallDir)atlmfcinclude
$(VCInstallDir)PlatformSDKinclude
$(FrameworkSDKDir)include
C:Program Files (x8
6)Microsoft Visual Studio 8VCATLMFCINCLUDE
C:Program Files (x86)Microsoft Visual Studio 8VCINCLUDE
C:Program Files (x86)Microsoft Visual Studio 8VCPlatformSDKinclude
C:Program Files (x86)Microsoft Visual Studio 8SDKv2.0include

Thanks.

-BO

Accedi per lasciare commenti

Steve Lionel (Intel)

Mar, 01/04/2008 - 13:22

If you want 64-bit integers you have to ask for them by declaring variables as INTEGER(8) and using the proper kind specifier on the constants, such as 3000000000_8. Just using the 64-bit compiler does NOT change the size of any data types. Default integer is still 32-bit. What you do get is a much larger address space and more registers.

Steve

Accedi per lasciare commenti

barakobama

Mar, 01/04/2008 - 15:11

I see.

I have another problem in debug mode and got the message:

"Visual Studio cannot debug because a debug target has not specified"

I changed something that was workingin debug mode.

Could you tell me what the message means?

-BO

Accedi per lasciare commenti

Steve Lionel (Intel)

Mar, 01/04/2008 - 16:58

If you right click on the project and select Properties then Debuging, there should be a value in the Command field. The default is "$(TargetPath)". If you changed that, you could get that problem. You'll also see this if you try to start debugging on a DLL or Library project (without having set the Command field.)

Steve

Accedi per lasciare commenti

barakobama

Mar, 01/04/2008 - 18:07

Thanks.

You are right, I started the debug from lib side.

-BO

Accedi per lasciare commenti

barakobama

Mar, 01/04/2008 - 18:40

Question 1:

If the default integer is 32bit, how we can access64 bit memory space

without using "integer*8 myint"?

I've running my code with "integer*(4)" on 64bit machines (linux/unix).

To access the 64bit memory space on my Xeon machine, I need to change my source code, which I do not want to do. Too much work.

Question 2:

Is there a way to get around this problem?

How are others doing with this EM64T thing.

Question 3:

I am going to make a another x64 on Opteron XP 64bit.

Will I have the same issue?

-BO

Accedi per lasciare commenti

TimP (Intel)

Mar, 01/04/2008 - 19:44

With default 32-bit integers, you can index arrays dimensioned up to 2 billion. This gives you 8GB per array for 32-bit data. The limitations don't change with brand of CPU, or between Windows and linux, or between compiler brands.

Accedi per lasciare commenti

jimdempseyatthecove

Mar, 01/04/2008 - 22:26

Tim18,

Depends on the bit mode of the processor, the addressing mode of the O/S,and on the language used.

32-bit "Flat Model" Virtual Address is calculated (Scale Index and Base) to 32 bits off of the base of a common selector (typically CS=DS=ES=SS, FS and GS _may_ point elsewhere but often DS=FS=GS). This provides for 32-bits of Virtual Address assuming all virtual addresses are mapped. Typically a portion of the address space is reserved for the O/S (2GB or 1GB) leaving practical address space of 2GB or 3GB. You could not dimension a float (4 byte element) to 2 billion elements as the 32-bit address calculations using scale of 4 would wrap (or GP fault).

32-bit "Segmented Model", same as above except the segment registers (selectors) can be individually mapped to a virtual address space that in total can be much larger than 32-bits. Any single address evaluation is to 32-bits off the base of the designated selector base. Therefore any single array would physically be limited to 4GB but in practice would be less.

64-bit "Flat Model" 32-bit integers used for indexing an array are copied to 64-bit register before effective address calculations and where if 32-bit integer were signed, sign extension is used in copy and if unsigned sign extension is not used. Therefore you could have an array dimensioned to 2 billion or 4 billion elements (8GB or 16GB) but could be larger (multi-dimension each indexed with 32-bit integer).

64-bit "Flat Model" 64-bit integers used for indexing...

Jim Dempsey

Blog: The Parallel Void

www.quickthreadprogramming.com

Accedi per lasciare commenti

Steve Lionel (Intel)

Mer, 02/04/2008 - 07:20

Jim, that's interesting but I don't quite see the relevance.

In a 64-bit environment, virtual addresses are 64-bits. That means that you can have more than 2GB of code and data, and indexing of arrays larger than 2GB is possible. You do not need to declare integer variables as integer(8) in order to index large arrays, as Tim notes, though if you have more than 2 billion elements in the array, you'll want to do that. The compiler will take care of any conversions needed for indexing in the 64-bit address space.

64-bit Windows does have one serious limitation - the total size of code and static data (not allocated at run-time) cannot exceed 2GB. This means you cannot do something like this:

real big_array(2000000000)

If you want large arrays, you will have to make them ALLOCATABLE (or POINTER) and use ALLOCATE to create them at run-time. This is a Windows design issue, not the compiler.

Steve

Accedi per lasciare commenti

Igor Levicki

Mer, 02/04/2008 - 08:08

Jim, one bit of caution though — in Windows pointers are signed. So watch out your pointer arithmetic carefully, what worked in 32-bit mode might fail in 64-bit mode.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

Accedi per lasciare commenti

barakobama

Mer, 02/04/2008 - 14:04

Thanks for your reply.

My question was:

How can I access to an address with a pointer biggerthan 2^32 while usingdefault integer(integer *4)without changing it to integer*8.

And I do not see any options related to the OFFSET, or SEGMENTED/FLAT MODEL in the VS2005.

I am talking about x64 case.

The fact that default integer is only 32bit is a huge headache to me and I am wondering what other people are doing to addresss this issue.

EM64T is not really 64bit and not that useful to me unless I can solve this problem.

-BO

Accedi per lasciare commenti

Igor Levicki

Mer, 02/04/2008 - 14:32

You asked for the second time:

How can I access to an address with a pointer bigger than 2^32 while using default integer(integer *4) without changing it to integer*8.

I think it is time to take out the analogy gun...

It is as if you have asked "How can I play both bass and melody part simultaneously on a concert piano using just one hand?" You can't it is impossible to address more than 2GB of memory using 32-bit pointers.

You can still use 32-bit integers for your data, but your pointers must be 64-bit in order to access more memory.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

Accedi per lasciare commenti

barakobama

Mer, 02/04/2008 - 14:56

Sorry, I did not know this thread had 2 pages.

Anyway, without your help, I couldn't have come this far.

Thanks.

-BO

Accedi per lasciare commenti

Steve Lionel (Intel)

Mer, 02/04/2008 - 15:25

Igor, I don't think that's what's being asked. The issue is array index variables. As Tim and I note, you can use "default integer" variables to index into 64-bit arrays, but that assumes that you do not have more than 2G elements in any one dimension. If you do, then you have no choice but to use INTEGER(8) variables for indexing. This is the same across every 64-bit platform I have used, going back to DEC Alpha in 1992.

Steve

Accedi per lasciare commenti

Igor Levicki

Mer, 02/04/2008 - 15:54

Steve, I am sorry but his question wasn't very clear. He just said that he is reluctant to go and change all of his integers to 64-bit. He never said whether he is using them as indices or as pointers. To be honest we would be able to assist him better and faster if he described what he wants to accomplish in more detail.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.

Accedi per lasciare commenti

Steve Lionel (Intel)

Mer, 02/04/2008 - 17:44

If he was using the integers as pointers, the matter would not come up, as in Fortran he could not use 32-bit integers as pointers on a 64-bit system (in that the compile would fail, and this would also require him to use the "Integer pointer" extension). I think he's talking about array indexes. But I agree that it isn't perfectly clear.

Steve

Accedi per lasciare commenti

barakobama

Ven, 04/04/2008 - 16:36

How can I set default integer for C side for 64bit.
We can do it by setting "Property>Fortran>Data>Default Integer KIND 8" in Fortran.
But I do not see it in C project.

Probably related to this, I see some weird thing under Options.
After I set the "x64" for Paltform under
Tools>Options>Porjects and Solutions>VC++ Directories,
it put "Win32" back when I come back and reopen the Options
while the "Target Platform" under "Intel Fortran" stays as "x64" with
Seletect Compiler as "IA32_EM64T].

-BO

Accedi per lasciare commenti

Steve Lionel (Intel)

Ven, 04/04/2008 - 17:34

If there's an option to do this in C, I don't know it. Sometimes there's a way to make "long" a 64-bit type. On 64-bit Windows, it's 32-bit by default, but on Linux it's 64-bit. int is 32-bit everywhere. You can ask over in the C forum if there's a way to set longs as 64-bit.

The Options page does NOT set the project target. This is where you can modify paths used for different target builds. You can set paths for Win32 (32-bit), for x64, and for Itanium if you have the Team System Edition. The Options page will always default to Win32 and affects all your projects.

You use the Target Platform for the project to set the target type.

Steve

Accedi per lasciare commenti

jimdempseyatthecove

Ven, 04/04/2008 - 18:58

BO,

When creating a new subject could you please create a new forum thread as opposed to changing the subject line on a Reply toan existing thread. Reason being is the threads are indexed by the original subject line and not the last subject line. It is hard to locate the newly posted threads with different subject lines to locate the new posting.

Jim

Blog: The Parallel Void

www.quickthreadprogramming.com

Accedi per lasciare commenti

PeterTheRascal

Sab, 30/03/2013 - 07:26

Hi Steve? I just upgraded: from: w_fcompxe_novsshell_2013.1.119.exe; (I think) to: w_fcompxe_novsshell_2013.3.171.exe and my Fortran Win32 DLLproject(s), with no C++, ;now give the message ;fatal error LNK1104: cannot open file 'ifconsol.lib' Having waded through this forum I reckon I need some advice! I can see the file in C:\Program Files (x86)\Intel\Composer XE 2013\compiler\lib\ia32\; and; \intel64\

Update; even though there is no (explicit) C++ I tried, without success:

"In Visual Studio, go to Tools > Options > Projects > VC++ Directories. For "Library Files", add the full path to the Intel Fortran "Lib" folder"

Peter

Accedi per lasciare commenti

Steve Lionel (Intel)

Dom, 31/03/2013 - 15:59

Peter, that would have no effect for a Fortran project. Please set the project property Linker > General > Show Progress > Show some progress messages), do a rebuild, and then attach a zip of the buildlog.htm from the Debug folder.

Steve

Accedi per lasciare commenti

PeterTheRascal

Lun, 01/04/2013 - 03:12

Steve, Build logn i attached.

Peter

Allegati:

Allegato	Dimensione
Scarica debug.zip	2.3 KB

Accedi per lasciare commenti

Steve Lionel (Intel)

Lun, 01/04/2013 - 08:26

Ok - well, that didn't tell me much.

What do you have listed under Tools > Options > Intel Composer XE > Visual Fortran > Compiler > Libraries?

I assume you saw the compile error for the directive that is missing the routine name. I had fixed this when I was playing with your project earlier.

Steve

Accedi per lasciare commenti

PeterTheRascal

Lun, 01/04/2013 - 09:41

Steve

$(IFortInstallDir)lib\ia32;$(VCInstallDir)atlmfc\lib;$(VCInstallDir)lib;$(WindowsSdkDir)lib

Sorry if there was an error. This verison comple fine on my spare PC.

Peter

Allegati:

Allegato	Dimensione
Scarica buildlog.zip	1.23 KB
Scarica fcall3.zip	37.57 KB

Accedi per lasciare commenti

Steve Lionel (Intel)

Lun, 01/04/2013 - 09:48

You didn't provide the information from Tools > Options I asked for.

Steve

Accedi per lasciare commenti

PeterTheRascal

Lun, 01/04/2013 - 11:40

Oops. I did not noitice the ..,

$(IFortInstallDir)lib\ia32
$(VCInstallDir)atlmfc\lib
$(VCInstallDir)lib
$(WindowsSdkDir)lib

Peter

Accedi per lasciare commenti

Steve Lionel (Intel)

Lun, 01/04/2013 - 11:49

That looks ok. Try putting in the full path to the lib\ia32 folder in that list as a workaround.

Steve

Accedi per lasciare commenti

PeterTheRascal

Lun, 01/04/2013 - 12:48

Thanks. Thr patch works provided the full path is first e.g.

'C:\Program Files (x86)\Intel\Composer XE 2013\compiler\lib\ia32'
$(IFortInstallDir)lib\ia32
$(VCInstallDir)atlmfc\lib
$(VCInstallDir)lib
$(WindowsSdkDir)lib

How can I find the value of my "$(IFortInstallDir)" or some other sysmbol? ThoughI guess if it was wrong nothing would work?

Thanks

Accedi per lasciare commenti

Steve Lionel (Intel)

Lun, 01/04/2013 - 13:08

I too would have expected it would either work everywhere or nowhere. I know we had some issue with these pseudo-environment-variables in Update 2 that were fixed in Update 3, but perhaps there is some lingering issue. The values come from the registry when Fortran is installed.

Steve

Intel® Developer Zone