Error #10037: could not find 'lib'

Error #10037: could not find 'lib'

I have a problem creating static libraries in IVF XE 13.1.0.149 with VS 2008. The "Lib" executable could not be found when creating the library. Also, after upgrading to the latest IVF version, a warning message saying that "mspdb80.dll" or "mspdb100.dll" could not be found occurs when compiling the 64-bit version. The error messages are the following:

++++++++++++++++++++++++++++++++++++++++++

32-bit build:

Compiling with Intel(R) Visual Fortran Compiler XE 13.1.0.149 [IA-32]...
ifort /nologo /debug:full /Od /warn:interfaces /module:&quotDebug\\&quot /object:&quotDebug\\&quot /Fd&quotDebug\vc90.pdb&quot /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /c /extfor:f /Qvc9 /Qlocation,link,&quotC:\Program Files (x86)\Microsoft Visual Studio 9.0\Intel Fortran\Microsoft Files\VC\\bin&quot &quotY:\Documents\Matrix\ISIS2_euclid\mv\BlasDotWrap.f&quot
Creating library...
Lib /OUT:&quotDebug/Forlib.lib&quot /NOLOGO &quotDebug\BlasDotWrap.obj&quot
xilib: executing 'lib'
xilib: error #10037: could not find 'lib'
Lib: error spawn_errno_default: spawn('C:\PROGRA~2\Intel\COMPOS~1\bin\ia32\xilink.exe') failed, errno=0

Forlib - 2 error(s), 0 warning(s)

------------------------------------------

64-bit build:

Compiling with Intel(R) Visual Fortran Compiler XE 13.1.0.149 [Intel(R) 64]...
ifort /nologo /debug:full /Od /warn:interfaces /module:&quotx64\Debug\\&quot /object:&quotx64\Debug\\&quot /Fd&quotx64\Debug\vc90.pdb&quot /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /c /extfor:f /Qvc9 /Qlocation,link,&quotC:\Program Files (x86)\Microsoft Visual Studio 9.0\Intel Fortran\Microsoft Files\VC\\bin\amd64&quot &quotY:\Documents\Matrix\ISIS2_euclid\mv\BlasDotWrap.f&quot
warning #31001: The dll (mspdb80.dll or mspdb100.dll) for reading and writing the pdb could not be found on your path. This is usually a configuration error.Compilation will continue using /Z7 instead of /Zi, but expect asimilar error when you link your program.

Creating library...
Lib /OUT:&quotx64\Debug/Forlib.lib&quot /NOLOGO &quotx64\Debug\BlasDotWrap.obj&quot
xilib: executing 'lib'
xilib: error #10037: could not find 'lib'
Lib: error spawn_errno_default: spawn('C:\PROGRA~2\Intel\COMPOS~1\bin\Intel64\xilink.exe') failed, errno=0

Forlib - 2 error(s), 1 warning(s)

++++++++++++++++++++++++++++++++++++++++++

The workaround/solution for these problems is to modify the "Executables:" path in VS 2008 as follows:

1.) Select "Tools->Options"

2.) Expand "Intel Composer XE"

3.) Expand "Visual Fortran"

4.) Select "Compilers"

5.) For 32-bit:
     a.) Under "Platform:", select "Win32"
     b.) Select "..." for "Executables:"
     c.) Add the following:
         "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin"
         under
         "$(VCInstallDir)BIN"
     d.) Select "OK"

6.) For 64-bit:
     a.) Under "Platform:", select "x64"
     b.) Select "..." for "Executables:"
     c.) Add the following:
         "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64"
         under
         "$(VCInstallDir)bin\amd64"
     d.) Select "OK"

38 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di Steve Lionel (Intel)

Did this work with Update 1?  Are you using the VS2008 Shell or a regular install of VS2008?

Steve

I first tried to create the libraries on Update 2. Then, I uninstalled Update 2 and reinstalled Update 1, but still couldn't create a library.

I'm using the regular install of VS2008.

Ritratto di Steve Lionel (Intel)

What is the content of Tools > Options > Intel Composer XE > Visual Fortran > Compiler > Executables (without any changes you made)?

Steve

Win32:

$(IFortInstallDir)bin\ia32
$(VSInstallDir)Common7\IDE
$(VCInstallDir)BIN
$(VSInstallDir)Common7\Tools
$(VSInstallDir)Common7\Tools\bin
$(FrameworkDir)$(FrameworkVersion)
$(WindowsSdkDir)bin
$(PATH)

x64:

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

Ritratto di Steve Lionel (Intel)

That all looks correct.  Please try logging out and in again and see if the build still fails. If it does, try a reboot. I've seen this fix similar issues.

Steve

Both logging out and in and rebooting didn't work.

Steve, Isn't this the same problem as I had (VS Settings again) . The path in the first post includes \Intel Fortran\Microsoft Files\VC which presumably doesn't exist as the fix was to add the true VS2008 path to VC. Presumably update 2 is configuring the property page macros incorrectly.

Ritratto di Steve Lionel (Intel)

The path with "Microsoft Files" would be correct if you were using the included VS Shell and Libraries. It would not be correct if using a "retail" version of Visual Studio.

We've had several complaints of this issue with Update 2 and are trying to understand it.

Please do the following.  First, click on the Windows button and type regedit.exe into the search box and press Enter. Browse to the key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC , copy the value of the ProductDir value and paste it into a reply here.

Next, in VS right click on your Fortran project and select Properties. Go to Build Events > Pre-Build Events. In Command Line, type:

echo "%PATH%"

and click OK. Now do a build. Attach a ZIP of the buildlog.htm to a reply here.

Steve

ProductDir Value: c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\

There was no build.htm file created during the build, so I put the output in a file and zipped it up.

Allegati: 

AllegatoDimensione
Download build.zip1.1 KB
Ritratto di Steve Lionel (Intel)

Thanks, that was very helpful. I was looking for buildlog.htm which would be in the Debug folder, but this was ok.

For some reason, the Fortran integration thinks you have the VS2008 Shell rather than the full VS2008. The workaround for now is as you discovered - putting the full path to the VC\BIN folder in the Executables folder list.  I am not sure why some people see this and some don't. I will let the developers know about it - we apologize for the inconvenience.

Steve

Understood. Thanks for your help with the issue.

Ritratto di Steve Lionel (Intel)

The developers tell me that they think they fixed this in Update 3. They also suggest that if you replace $(VCInstallDir) with $(VSInstallDir) it may help as a workaround.

Steve

No problems after installing Update 3. Thanks.

Steve

Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.0.103 Build 20130728

Visual Studio Shell 2008

Winteracter 9.2c
Windows 7 x64

I have a similar issue. I am using the Winteracter development environment to build my exes. It gives me the choice of getting the environment settings from VS or my path, I've tried both.

On compilation with the following switches

-c -include:"C:\Program Files (x86)\compiler\WINTER\lib.i64" -Qvec-report0 -check:all -debug:full -traceback -warn:all -heap-arrays

I get the following error

warning #31001: The dll for reading and writing the pdb (for example, mspdb110.dll) could  not be found on your path. This is usually a configuration error. Compilation will continue using /Z7 instead of /Zi, but expect a similar error when you link your program.

However unlike the OP the program links and created an exe which rather than putting up an error message on crashing just shuts down. If I start my exe from a DOS shell then the error gets reported to the dos shell in the same way it would have done to a windows dialogue.

I uninstalled all versions of VS (2005, 2008 & 2010) as well as Composer XE, rebooted, manualy removed all the VS and Intel directories, ran regclean a couple of times, rebooted and reinstalled the full composer download

I don't have mspdb110.dll but do have mspdb100.dll in two places;

c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\Bin\amd64\

c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\

The two dlls are different sizes so not identical.

I tried adding the explicit path to the list of pathes in the VS exes as per the OP - no change. I tried changeing the references to VCInstalDir to VSInstallDir - no change. As neither VSInstallDir nor VCInstallDir were declared in my normal environment variables but VSShell2010InstallDir was I tried refeferencing the VSInstallDir lines to VSShell2010InstallDir - no change.

I tried running ifort from a command prompt established from Start\Intel ....\Command Prompt\....64 bit using the switches above. Same error message.

Any tips?

Cheers

Kim

Ritratto di Steve Lionel (Intel)

Kim, are you using the bundled Visual Studio? You talk about uninstalling and reinstalling VS, but the presence of the Shell folders and environment variables has me a bit puzzled. However, I have seen the installer get confused when installing the shell over remnants of an earlier VS install.

Please uninstall Fortran and the folloiwing additional items, if present:

Microsoft Visual Studio 2010 Shell (Integrated) - ENU
Microsoft Visual Studio 2010 Files for Intel Visual Fortran
Microsoft Visual Studio 2010 Remote Debugger – ENU

Delete the folder Program Files (x86)\Microsoft Visual Studio 10.0

Now if you have a regular VS2010, install that and then Intel Fortran. Otherwise, install the full Intel Fortran (including the Shell.) Let me know what happens.

Steve

Steve

Yes I'm using the bundled VS not a stand alone version.

Before my original post I did as you suggest as well as uninstalling VS2005 and 2008 which were leftovers from previous Visual Fortran instalations over the past 3 years. So to be clear - I uninstalled all the versions of VS, and any file groups that were associated with it. Uninstalled Fortran, rebooted and manually removed the residual directories from Program Files (x86). I then did a clean and full install of Fortran Composer XE. The only quirk I noted on installation was that a couple of screens in I got a message to say I had already integrated VF with VS 2010 and that continueing with the instalation would overwrite that integration so presumably there were some relics left in the registry that did not get removed with the uninstalation.

One thing I did not mention is that this has only been a problem for a few months but I think it started before the most recent update i.e I think it was happening during the later stages of version 13, I was just too busy to spend time worrying about it as the exes seemed to work. I had not had them crash and not report a windows format RT error though. It only happens when I compile using the 64 bit compiler/linker. 32 bit appears to be fine.

Cheers

Kim

Ritratto di Steve Lionel (Intel)

The link-time error should not cause any ill effects at run-time. Are you building from the VS environment or the command line?

Steve

Steve

The apparent lack of ill effects is why it has taken me a while to investigate. However the loss of windows run time error messages is enough of an ill effect to start me hunting.

I'm building from the IDE in Winteracter, however I also tried building from the command line using the shell created by the Intel 64 Visual Studio 2010 mode shortcut on the start menu and get the same error message.

I suspect there are other dlls not being found and not reported when I compile in optimised mode. When I compile in debug mode I get the error  31001 message but not when I compile in optimised mode. However both exes now terminate without displaying a windows run time error. If run from a DOS box rather than through Windows the run time error is reported to the DOS box along with the traceback. This is new behaviour as for the past 3-4 years run time errors have been reported to a window allowing the user to see what the problem was. My compiler switches in Winteracter have not changed. Just to reiterate; the problem only occurs when I compile in 64 bit mode, the 32 bit programs still display run time errors in a window.

Cheers

Kim

Ritratto di Steve Lionel (Intel)

Kim, I don't spot where you told me what the run-time error says.

Steve

Steve

I'm using it in the generic sense rather than talking about a specific run time error. The run time errors are either due to logic errors in my programming or bad data. That is not the problem. The problem is that coincident with the occurrance of my #31001 errors on compiling the debug version both the depug and production version exes now just crash if they encounter a run time error whereas they used to pop up a window displaying the error and traceback. If instead of launching the exe in Windows I launch it in a DOS box then run time errors are reported along with the trace back so it looks to me as if the build is not loading the components for intel to address the windows gui directly.

Cheers

Kim

Ritratto di Steve Lionel (Intel)

I don't think there's a connection there- it may just be coincidence. The error message and traceback you want doesn't use debug information. Would you please attach a ZIP of the buildlog.htm from a full build of the project?

Steve

Steve

I'm assuming buildlog.htm is created by VS as it does not exist on my system. I don't use VS at all although it is obviously installed and Winteracter uses settings from VS to know where the compiler files are. Hopefully the attached will do instead.

These are the reports from Winteracter while building - I assume they are just ported from the ifort messages.

I have compiled the same code using both the 32bit and 64 bit compilers so you can see the difference.

Cheers

Kim

Allegati: 

AllegatoDimensione
Download buildlog32.txt20.13 KB
Download buildlog64.txt40.07 KB
Ritratto di Steve Lionel (Intel)

My guess is that the compiler environment is not set up properly for your building from Winteracter. How do you begin the Winteracter session? You might have better luck, initially, with Winteracter support. This is not a build environment we can help with directly.

Steve

Thanks Steve

I appreciate that using a third party builder makes your job harder but I have been using a Winteracter + Intel VF combination for 3-4 years and not changed compiler switches since I switched to 64 bit compilation ~12 months ago. This problem started occuring in the past 3-4 months so is new. It happens on both my home machine and office machine so I don't see it likely as being due to some sort of file corruption.

Given that I don't have mspdb110.dll on my machine what file or files should I be looking for and I'll try and put it or them somewhere it can be found.

Cheers

Kim

Steve

One other thing that occured to me is that I get exactly the same error message when compiling from the DOS box created by the shortcut set up by Intel VF so although it complicates matters I don't think Winteracter is an issue here.

Cheers

Kim

Ritratto di Steve Lionel (Intel)

From that command environment, please do a SET PATH and show me the output. It may be that PATH is so long some things are getting left off.

Steve

Steve

To try and simplify the problem I took one of the distribution samples and compiled it from within the 64 bit compilation command line that is set up by the Intel instalation.

Here is what I did.

Click on Start\Programs\Intel Parallel Studio XE 2013\Command Prompt\Parallel Studio XE with Intel Compiler XE v14.0\Intel 64 Visual Studio 2010 mode.lnk to get a dos box with the environment variables set for 64 bit compilation

go to c:\Program Files (x86)\Intel\Composer XE 2013 SP1\Samples\en_US\Fortran\QuickWin\Scigraph\  and run build.

Program builds OK with no compiler errors.

Now edit build.bat to add /debug:all to the compiler switches e.g.

ifort /nologo /c /debug:all /libdir:noauto sgdata.f90
ifort /nologo /c /debug:all /libdir:noauto sglowlvl.f90
ifort /nologo /c /debug:all /libdir:noauto sgdraw.f90
ifort /nologo /c /debug:all /libdir:noauto sgplot.f90
ifort /nologo /c /debug:all /libdir:noauto sgadmin.f90
ifort /nologo /c /debug:all /libdir:noauto scigraph.f90

Now run build.

I get lots of warning #31001: The dll for reading and writing the pdb (for example, mspdb110.dll) could  not be found on your path. This is usually a configuration error. Compilation will continue using /Z7 instead of /Zi, but expect a similar error when you link your program.
errors.

That suggests to me that something has not been set properly during the installation. Remember that this is a clean reinstall and is happening on two separate machines. It did not always happen and does not happen for a 32 bit compilation.

Hope that explains the problem more clearly.

Your request just came through as I was about to send. Here is the path from the 64 bit dos prompt created above.

Path=C:\Program Files (x86)\Intel\Composer XE 2013 SP1\bin\intel64;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\intel64\compiler;C:\Program Files (x86)\Microsoft Visual Studio 10.0\\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 10.0\\Intel Fortran\Microsoft Files\VC\BIN\x86_amd64;C:\Program Files (x86)\Microsoft Visual Studio 10.0\\Common7\Tools;C:\Program Files (x86)\Microsoft Visual Studio 10.0\\Common7\Tools\bin;C:\Program Files (x86)\Microsoft Visual Studio 10.0\\Intel Fortran\Microsoft Files\VC\bin;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\intel64\mkl;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\intel64\compiler;C:\Program Files (x86)\Common Files\Microsoft Shared\VSA\10.0\VsaEnv;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\mpirt;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\mpirt;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler;C:\Program Files (x86)\compiler\WINTER\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\UBC-GIF\bin;C:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\Microsoft Windows Performance Toolkit\;C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\intel64\mpirt;
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

Looks like the bits I need are there.

Cheers

Kim

aaaaa Just looking at the path and see a possible problem; there are two back slashes between Microsoft Visual Studio 10.0 and Common7 which is the path that mspdb100.dll is stored in.

Could it be as simple as that?

Cheers

Kim

Ritratto di Steve Lionel (Intel)

I have found that the double-backslash isn't an issue. But what I do see is this:

You have in the path:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\\Intel Fortran\Microsoft Files\VC\BIN\x86_amd64;

but that's not where mspdb100.dll is. As you wrote above, it's in:

c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\Bin\amd64\

The first path would be for a cross-compiler,but the proper DLL for that is in \VC\Bin.

Try this experiment. Open the command prompt window and type:

set path="c:\Program Files (x86)\Microsoft Visual Studio 10.0\Intel Fortran\Microsoft Files\VC\Bin\amd64\";%PATH%

and try the build again. I see that our .bat file for the VS2010 shell adds the x86_amd64 folder to the path. I am a bit puzzled because if this was a general problem we'd have heard about it from MANY people so far. I need to look at this some more....

Steve
Ritratto di Steve Lionel (Intel)

Yes, in fact that is exactly the problem. I reproduced it.

The temporary fix is to edit C:\Program Files (x86)\Intel\Composer XE 2013 SP1\bin\vsshell2010vars_arch.bat (or without the SP1 if you have the older version.)

Find these lines:

:not_x86_arch  
  SET "PATH=%VSINSTALLDIR%\Common7\IDE;%VCINSTALLDIR%\BIN\x86_amd64;%VSINSTALLDIR%\Common7\Tools;%VSINSTALLDIR%\Common7\Tools\bin;%VCINSTALLDIR%\bin;%PATH%"

In the SET PATH, change "x86_amd64" to "amd64" and save. You may need to save this to the desktop and then copy it in to the folder as just saving it from Notepad will fail.  I will report this to the developers. It appears to affect building for debug from the command line only - if you build from Visual Studio you won't see this.

Steve
Ritratto di Steve Lionel (Intel)

Issue ID is DPD200248642. The edit I described won't be correct if you want to build a 64-bit app on a 32-bit system. If you want that, then simply add %VCINSTALLDIR%\BIN\amd64; just before ;%PATH%

Steve

Thanks Steve.

The time difference between us isn't helping a quick resolution, sorry:-)

Perhaps you are not being swamped by queries from users because not many are building 64 bit apps with debug full, preferring to go straight to production code?? Maybe also like me they are just putting up with it because it did not appear to effect the exe - it does but it is not immediately obvious.

I think there has to also be problems with the additions to the normal path and probably also the config for VS.

e.g. My normal path is;

Path=C:\Program Files (x86)\Common Files\Microsoft Shared\VSA\10.0\VsaEnv;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\mpirt;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\mpirt;C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler;C:\Program Files (x86)\compiler\WINTER\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\UBC-GIF\bin;C:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\Microsoft Windows Performance Toolkit\;C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;C:\Program Files (x86)\QuickTime\QTSystem\
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

The first entry is Path=C:\Program Files (x86)\Common Files\Microsoft Shared\VSA\10.0\VsaEnv; which does not exist on my machine! I have no VSA directory under Microsoft shared\ and I can't see 10\VsaEnv under any of the other directories in that sub path. There is a VSA directory under C:\Program Files (x86)\Common Files\Microsoft\ but it does not have a 10\ subdirectory.

I'm not sure where that path should have been pointing so cant guess at a fix.

Cheers

Kim

Ritratto di Steve Lionel (Intel)

Kim,

I told you above how to fix the problem. It affects people using the VS Shell on 64-bit systems building 64-bit applications, with debugging, from the command line (or a tool started from the command line.) Ignore the VSA folder.

Steve

Thanks Steve

My problem is that I do not usually build from the command line. I only did that to show that the problem had nothing to do with Winteracter. I need a solution that works through VS - which Winteracter uses to get its environemnt and path. That is why I suspect this config in the setup of the latest release has some other issues.  Certainly adding non existant directories to my path statement on instalation does not bode well.

For the moment I'll set up my normal path to point to the directories I need and tell Winteracter to use my path rather than VS but I'd appreciate it if you could also check the initial config for VS for a 64 bit machine making 64 bit apps.

If I get time over the weekend I'll read up on how to build a project from VS and try building the SGDemo with debug:all and see if I can show that it too has problems.

Cheers

Kim

Steve

I was able to build the exe in VS as a 64 bit app with debug:full and no errors so it looks like I'll have to dig deeper.

Thanks for your help

Cheers

Kim

Ritratto di Steve Lionel (Intel)

Kim,

I'm pretty sure that Winteracter is relying on the Intel Fortran command-line environment files to set up its environment. Visual Studio does something different, which is why it works.

I have attached here vs2010shellvars_arch.bat (in a zip file) with a fix to the bug (which has been in our product for a while now - it's not new.) If you copy this to the Intel Fortran "bin" folder for your version and restart the Winteracter environment, it should (I think) solve the problem.

Allegati: 

AllegatoDimensione
Download vsshell2010vars-arch.zip755 byte
Steve

Thanks Steve

That did not fix the Winteracter build problem I'm afraid.  I'll keep digging. I added the more obvious environment variables and path statements from the Studio 2010 for Intel 64 dos prompt with your path mods above to my environemnt settings and set Winteracter to use those but still no joy so I'll try adding some of the less obvious settings.

Cheers

Kim

Accedere per lasciare un commento.