can't make an x64 library

[Lori_Newhouse]

Im having difficulty making a library from fortran code in x64 mode. I have Intels fortran compiler integrated with Visual Studio 2010. I have made a new library project. For Win32, the library is successfully created. For x64, the compile works fine, but the creation of the library is failing. Here is the text from the log file:

Creating library...

Creating temporary file "RSP1.rsp" with contents
[
/OUT:"x64\\Debug/new_lib.lib" /NOLOGO /VERBOSE "x64\\Debug\\snsik.obj" (long list of obj files omitted)
]
Creating command line "Lib @"D:\\TFSWorkspace\\CFM latest\\source\\daskr\\new_lib\\new_lib\\x64\\Debug\\RSP1.rsp""

xilib: executing 'lib'

new_lib : error PRJ0019: A tool returned an error code new_lib - 1 error(s), 0 warning(s)

I made no changes to the properties except the addition of the VERBOSE option to the lib command line. I have no custom build steps. A coworker suggested I may need to be running VisualStudio as administrator; tried that and it didnt help.

I have looked thru the compiler documentation and the lib documentation. Didnt find anything I could relate to this error. Searched MSDN for PRJ0019. This seems to be a very generic error and there wasnt anything related to lib in the results.

[Les_Neilson]

Lori,
I have found that thiserror message is usually due to either the resource compile "rc.exe" or the manifest tool "mt.exe" failing. But I have no idea why they fail.
In my case a "rebuild" usually fixes it.

Les

[Lori_Newhouse]

Les,

Thanks for sharing your experience. It wouldn't be an exaggeration to say that over the past several days I have tried rebuilding this 100's of times. Tried rebuild; tried clean, then build; tried manually deleting entire directory containing obj's and build.

Yesterday I started running lib from a VisualStudio command prompt. Have situations where I can make a lib file and others where I cant. Im starting in a location where directory x64\Debug contains the objs. The following works and the lib file is created
lib /OUT:x64\Debug\test_lib.lib x64\Debug\datv.obj x64\Debug\daxpy.obj

I delete the lib file and try the following. It does not work; says it cant open the lib file.
lib /OUT:x64\Debug\test_lib.lib x64\Debug\datv.obj x64\Debug\daxpy.obj

If I remove the quotes from the lib file name, it cant find the first obj file. The lib command line used in the VisualStudio project has all those quotes.

Next, I moved down into directory x64. Both of these work.
lib /OUT:Debug\test_lib.lib Debug\datv.obj Debug\daxpy.obj
lib /OUT:Debug\test_lib.lib Debug\datv.obj Debug\daxpy.obj

[Steven_L_Intel1]

Lori,

Try copying your project tree to another folder, say, under your desktop. Does the problem still occur? Since you're invoking "lib" directly that leaves the Intel "prelinker" xilib out of the picture. Also try temporarily disabling your antivirus program and see if that changes things.

[Lori_Newhouse]

Steve,

My antivirus software is already excluding the directory I'm working in.

I made a new directory test_dir\Debug on my other hard drive and copied the obj's into it. Didn'tcopy theoriginal directory, just the obj's. Getting the same behavior with this new directory.

I changed the name of x64\Debug to trial\Debug thinking perhaps something special was being triggered by the x64 in the name. No change in behavior.

I'm puzzled by the behavior with quotes around the file names. The lib command can handle stepping down 1 directory with quotes but not down 2 directories. I triedsimilar lib command lines for the Win32 debug obj's. Both of these work. (The Visual Studio project by default uses Debug and Release as the directories when building Win32; it doesn't make a Win32 directory.)


lib /OUT:"Debug\test_lib.lib" "Debug\datv.obj" "Debug\daxpy.obj"
lib /OUT:"new_lib\Debug\test_lib.lib" "new_lib\Debug\datv.obj" "new_lib\Debug\daxpy.obj"

I'm going to switch to a different project type. Right now, I'm using the fortran library template. Am going to try a main program then add custom build steps to execute lib. I've never used custom build steps, so it will take me a bit of time to figure that out. I know I'll need to use the compiler option that says I don't have a main.

Lori

[Steven_L_Intel1]

Lori,

If you use a "main program" project type I don't think you can prevent the attempt to link. This is all very puzzling, as I'm sure you'll agree.

The default way that VS sets up Win32 projects is that there is no platform-named subfolder the way there is for x64.

[Lori_Newhouse]

Two coworkers looked over my shoulder and watched what I was doing. They made 2 suggestions that have helped clear up some issues.

We look at the information in the log file from Visual Studio:

Creating library...
Creating temporary file "RSP1.rsp" with contents
[
/OUT:"x64\Debug/new_lib.lib" /NOLOGO /VERBOSE "x64\Debug\snsd.obj" "x64\Debug\sinvwt.obj" long list of obj files omitted
]
Creating command line "Lib @"D:\TFSWorkspace\CFM latest\source\daskr\new_lib\new_lib\x64\Debug\RSP1.rsp""
xilib: executing 'lib'
new_lib : error PRJ0019: A tool returned an error code
new_lib - 1 error(s), 0 warning(s)

One coworker pointed out that I don't seem to be doing EXACTLY what the log file has. It's putting the command line options in a text file while I'm entering them directly. The other was concerned that I was copy-and-pasting my command line from a Word doc. What you see is not necessarily what you've got as there could be stealth characters lurking about. I put the command line options in a txt file. I also typed my command line into a txt file and did the copy-and-paste from there. All of the commands below work to create the lib file (using a Visual Studio command prompt.)

lib /VERBOSE /OUT:x64\Debug/test_lib.lib x64\Debug\datv.obj x64\Debug\daxpy.obj

lib /VERBOSE /OUT:"x64\Debug/test_lib.lib" "x64\Debug\datv.obj" "x64\Debug\daxpy.obj"

lib @"command_options_no_quotes.txt"

lib @"command_options_quotes.txt"

Next, I tried using the xilib command. Both of these command lines work.

"C:\Program Files (x86)\Intel\ComposerXE-2011\bin\ia32\xilib.exe" -out:x64\Debug\test_lib.lib x64\Debug\datv.obj x64\Debug\daxpy.obj

"C:\Program Files (x86)\Intel\ComposerXE-2011\bin\intel64\xilib.exe" -out:x64\Debug\test_lib.lib x64\Debug\datv.obj x64\Debug\daxpy.obj

This is some progress as all the ways that SHOULD work to create the library actually DO work. But, I stilldon't know what is going wrong during the Visual Studio build. Is there a way I can get the exact command lines executed by Visual Studio?

[Steven_L_Intel1]

Try this experiment. Open the C:\Program Files (x86)\Intel\ComposerXE-2011\bin\intel64 folder. rename xilib.exe to xilib2.exe (this will require Administrator privileges on Vista/Win7.) Now copy C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\lib.exe into the Intel bin folder and rename it xilib.exe. Now try a build - does it work or fail with the same error? You may need to copy link.exe instead of lib.exe (lib.exe is just a jacket for link.exe).

[Lori_Newhouse]

Steve, thank you very much for this suggestion. It started me on a path that lead to successfully building in Visual Studio. I made a change in the VS options and I'd like to get your perspective on that change.

As you suggested, I copied the MS directory lib.exe and link.exe to the Intel directory and renamed them to xilib.exe. When trying to build in VS, I get a pop-up saying
xilib.exe application error--application was unable to start correctly

Also, the log file does not contain the line
xilib: exectuing 'lib'

Get same pop-up when running xilib from the command line.

With the original xilib, the pop-up says

lib.exe application error--application was unable to start correctly
And the log file does contain the line
xilib: exectuing 'lib'

I saw there were lib.exe files in several of the. . .\VC\bin directories. Wondered which one was being used when I was working at the command prompt. Also, I was selecting the start menu option "Visual Studio Command Prompt (2010)". There is another, "Visual Studio x64 Win64 Command Prompt (2010)". Tried both command prompts with all of the different lib.exe's. Here are the results.

for "Visual Studio Command Prompt (2010)"
these work fine
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\lib.exe" @"command_options_no_quotes.txt"
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\lib.exe" @"command_options_no_quotes.txt"
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_ia64\lib.exe" @"command_options_no_quotes.txt"

this gives application unable to start correctly
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\lib.exe" @"command_options_no_quotes.txt"

for "Visual Studio x64 Win64 Command Prompt (2010)"
these work fine
same as above

these give application unable to start correctly
lib @"command_options_no_quotes.txt"
lib /VERBOSE /OUT:x64\Debug/test_lib.lib x64\Debug\datv.obj x64\Debug\daxpy.obj
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\lib.exe" @"command_options_no_quotes.txt"

To do more testing in VS, I changed the name of lib.exe and link.exe in . . .\VC\bin\amd64. Expected that building in VS would give error that it can't find lib. But, the build WORKED, I got the library. This was the FIRST time I got the library via a VS build. Then also changed the names in . . .\VC\bin. Now the VS build says it can't find lib.

I didn't see anything in Project | Properties that specifies the paths for xilib and lib. Looked around in other menues. In Tools | Options | Intel Visual Fortran | Compiler for platform=x64, "Executables" is this
$(IFortInstallDir)bin\Intel64
$(VSInstallDir)Common7\ide
$(VCInstallDir)bin\amd64
$(VCInstallDir)bin
$(VSInstallDir)Common7\Tools
$(VSInstallDir)Common7\Tools\bin
$(FrameworkDir)$(FrameworkVersion)
$(WindowsSdkDir)bin
$(PATH)

I moved bin\amd64 down and undid all my file name changes. The VS build works fine and I get my library.

I don't know what else will be impacted by this change. Do you think this change is reasonable?

[Steven_L_Intel1]

This is interesting. Are you on an x64 system?

Microsoft provides two variations of tools for x64. The ones in \amd64 are native x64 applications and run only on x64 systems. The ones in \x86_amd64 are cross-build tools that run on x86 but create x64 output. The tools in \bin are native x86.

The list you show above is what I would expect to see on an x64 system. What you did was use the x86 tools instead of the x64 tools, and this might cause you problems down the road (maybe not - not sure.)

What you did to "fix" the problem suggests to me that the x64 Visual C components are corrupted or incorrect. You may want to uninstall Fortran, do a "repair" on VS10, and then reinstall Fortran to see if that helps. You should click "Reset All" in the Visual Fortran > Compilers page to reset the lists before you test.

[Lori_Newhouse]

Steve,

I am using Windows 7 Enterprise. Have been on it only about 9 months. This is my first experience with an x64 OS. I am definitely not a Microsoft developer. Am an engineer that develops computational software. I appreciate you explanation regarding all the different lib.exe's.

Making this fortran library is just a piece of the bigger task. The rest of the code is in "c" and we are using MKL. Only part of the team will be working on the fortran. The rest will only be working on "c" and will not have a fortran compiler. So, I need to make this library for them to link to. Then make sure I can get everything else compiled x64 and get it all linked.

I copied the . . .\VC\bin\amd64\lib.exe from our build machine to my machine. Tried running it in the x64 VS command prompt. Got the same message about being unable to start correctly.

I will try to repair my VS10 install. Probably won't get to it for several days, so Idon't expect to post the results of that here until next week.

Lori

[Steven_L_Intel1]

You would also need to copy link.exe as lib.exe just turns around and calls link.exe.

It might be helpful to understand the problem if you'd download Dependency Walker, run it, drag the lib.exe onto it and then do File..Save to save a .dwi file, which you can then attach to a reply here.

No problem with your waiting until you get the time to work on this further.

[Lori_Newhouse]

Oh, that's right. You did say in an earlier post that lib is a wrapper for link, but I forgot. I copied both over to my machine from my build machine. Still get the error about application unable to start correctly. I thought about copying my obj's to the build machine and running lib there. But, that machine is on a 32 bit OS.

I tried running link directly. Wasn't sure about the command line options to create a lib rather than an exe, but took a stab at them. Ran this line from a VS2010 x86 command prompt:

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\link.exe" /VERBOSE /DLL x64\Debug\datv.obj x64\Debug\daxpy.obj

It did start executing and I got status messages about progress. But there was a fatal error, sounds like it couldn't find a fortran library. Ok, I can probably clear that up, but didn't try. I tried this line from a VS2010 x64 command prompt:

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\link.exe" /VERBOSE /DLL x64\Debug\datv.obj x64\Debug\daxpy.obj

This gave the now familiar message about application unable to start correctly.

A coworker told me that in VS2010, you can change the toolset to by "90" and it will use lib and other tools from VS2008. I do have both of these installed. The option should be in project properties | general | platform toolset. But, I don't see that for this fortran library project. So, I went to a VS2008 x64 command prompt; tried both of these lines:
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\lib.exe" @"command_options_no_quotes.txt"
lib @"command_options_no_quotes.txt"
Both worked and the lib was created. Finally, some good news.

I will make a fortran library project in VS2008 and see if it builds there.

I will also try tomake a library from some of my "c" source obj's with theVS2010 x64 lib command.

Haven't tried to repair my install yet. Also, haven't tried DependencyWalker yet. (I do have it and have used it in the past.)

[Lori_Newhouse]

I tried the lib command at a VS2010 x64 command prompt using obj's made from some of my "c" code. Got the same error about not being able to start correctly.

I made a VS2008 solution file using my existing vfproj file. That is building the x64 library fine.

I repaired my VS2010 installation. That did not clear up the problem.

[Steven_L_Intel1]

I suggest at this point an uninstall of Fortran, uninstall of VS2010, delete the Visual Studio 10.0 folder and then reinstall VS and Fortran.