linking problem

[moortgatgmail_com]

Hi ,
I'm running into an extremely annoying linking problem. I generally work under linux and/or mac osx (with makefiles), but in the end I have to compile our code for windows users using the visual studio (and as might be apparent, I'm much less accustumed to this). This is where I run into a linking issue, that I really don't understand and can't resolve. My code compiles fine, but then on linking gives the error:

1>Linking...
1>ipo: remark #11055: Il version for C:\Documents and Settings\Office\Desktop\FRSG_windows\Solver\umfpackdf.lib (1.21590.2.398) does not match compiler's il version (1.24797.2.700.2.513), ignoring object file
1>ipo: remark #11055: Il version for C:\Documents and Settings\Office\Desktop\FRSG_windows\Solver\umfpackdf.lib (1.21590.2.398) does not match compiler's il version (1.24797.2.700.2.513), ignoring object file
1>ipo: remark #11055: Il version for C:\Documents and Settings\Office\Desktop\FRSG_windows\Solver\umfpackdf.lib (1.21590.2.398) does not match compiler's il version (1.24797.2.700.2.513), ignoring object file
1>ipo: remark #11055: Il version for C:\Documents and Settings\Office\Desktop\FRSG_windows\Solver\umfpackdf.lib (1.21590.2.398) does not match compiler's il version (1.24797.2.700.2.513), ignoring object file
1>ipo: remark #11055: Il version for C:\Documents and Settings\Office\Desktop\FRSG_windows\Solver\umfpackdf.lib (1.21590.2.398) does not match compiler's il version (1.24797.2.700.2.513), ignoring object file
1>ipo: remark #11055: Il version for C:\Documents and Settings\Office\Desktop\FRSG_windows\Solver\umfpackdf.lib (1.21590.2.398) does not match compiler's il version (1.24797.2.700.2.513), ignoring object file
1>ipo: remark #11055: Il version for C:\Documents and Settings\Office\Desktop\FRSG_windows\Solver\umfpackdf.lib (1.21590.2.398) does not match compiler's il version (1.24797.2.700.2.513), ignoring object file
1>Embedding manifest...
1>
1>Build log written to "file://C:\Documents and Settings\Office\Desktop\FRSG_windows\FRSG_windows\Debug\BuildLog.htm"
1>FRSG_windows - 0 error(s), 0 warning(s)
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========


Now, the message seems self-explanatory, in that the only library I need to link, umfpackdf.lib, would be compiled using a different version of the compiler. I'd like to recompile the libary just as a check, but don't have access to its source. I know that this is not really the problem/case though: the same code has been linked to this library many times before on the same computer and with the same compiler. Somehow, changes have been made in the (fortran) source code, that result in a problem with the linker. However, none of these changes have anything to do with the solver (which is the library under consideration) and no other libraries are used. I would Greatly appreciate and suggestions on how to resolve this issue.

Thanks!
--J

[Steven_L_Intel1]

The library you are linking to was compiled with an Intel compiler and the /Qipo option. This puts compiler intermediate code in the library rather than normal object code. The message you are getting says that you are also using /Qipo and your version of the compiler is different from the version used to compile the library.

Try not using /Qipo in your build - that may work. Ideally, you should try to obtain a library NOT built with /Qipo.

[moortgatgmail_com]

Quoting - Steve Lionel (Intel)

The library you are linking to was compiled with an Intel compiler and the /Qipo option. This puts compiler intermediate code in the library rather than normal object code. The message you are getting says that you are also using /Qipo and your version of the compiler is different from the version used to compile the library.

Try not using /Qipo in your build - that may work. Ideally, you should try to obtain a library NOT built with /Qipo.

Thanks for the extremely fast response. I'd like to give your suggestion a try, but can't see whether I'm using /Qipo in the first place (I guess I am, given the error message), or how to turn it on/off??

I'm trying to compile with the 10.1.011 compiler (I could update, but given the specific error message, I'm afraid it mightexacerbatethe mismatch between library and compiler). I found a different thread explaining how to turn off the Interprocedural Optimization in the Project Properties, but these options are not available in my version here.

Also, I'm still extremely puzzled how this error occurs in the first place: I compiled on a colleagues laptop, using the same version of the code/library and compiler and it compiled without errors, linking or otherwise. Then I simply changed a variable in my code from true to false (no libraries or functions or anything involved), and upon re-compilation, I'm now running into the same linking error on his computer.

Any further suggestions would be most welcome.

--J

BTW: this might help too: I'm compiling in Debug mode, and optimization is disabled (/Od ); the command line tab states: /nologo /Zi /Od /gen-interfaces /warn-interfaces /module:"Debug" /object:"Debug" /traceback /check:bounds /libs:static /threads /dbglibs /c

The linker doesn't seem to have any relevant options (/OUR /NOLOGO /MANIFEST .. /DEBUG /PDB /SUBSYSTEM:CONSOLE /incremental:no )

[Steven_L_Intel1]

I assume you are building from Visual Studio. Go to the Fortran > Command Line property page and see if under All Options you see /Qipo there. It may also be entered under Additional Options, in which case you can remove it.

However, I would not expect that changing a variable would cause this error. Can you attach a ZIP of the project, including the library in question?

[moortgatgmail_com]

Quoting - Steve Lionel (Intel)

I assume you are building from Visual Studio. Go to the Fortran > Command Line property page and see if under All Options you see /Qipo there. It may also be entered under Additional Options, in which case you can remove it.

However, I would not expect that changing a variable would cause this error. Can you attach a ZIP of the project, including the library in question?

Here is the zip file of the project. [just checking though: the contents are not visible to the public, right? I don't think my institute would allow that]

As a further follow up: the Command line options do not include /Qipo, and I do not see Additional Options either.
Thanks

[Steven_L_Intel1]

Yes, attachments here are public, but I downloaded it and then removed it from your post. I'll take a look at this tomorrow.

[Steven_L_Intel1]

As I suspected, umfpackdf.lib was compiled with an older Intel compiler specifying -ipo. You're going to have to recompile it. umfpack.lib, on the other hand, is normal. Remove the /Qipo- from your project. I can't explain why you are suddenly seeing the problem unless you did something that caused umfpackdf.lib to be required.

[moortgatgmail_com]

Quoting - Steve Lionel (Intel)

As I suspected, umfpackdf.lib was compiled with an older Intel compiler specifying -ipo. You're going to have to recompile it. umfpack.lib, on the other hand, is normal. Remove the /Qipo- from your project. I can't explain why you are suddenly seeing the problem unless you did something that caused umfpackdf.lib to be required.

Thanks for your suggestion. The /Qipo- was just my last attempt to compile without IPO, as I can't find any menu options to turn it off. Also, when I look at the command line options for compiling and linking, /Qipo is not there, so I don't know why Visual Studio still wants to compile with IPO.

Indeed I don't get the same IPO error when linking to umfpack.lib instead of the other library (but it does warn me that certain functions are not found: these are required and defined inmfpackdf.lib). Unfortunately though, the actual routines required for the solver are in theumfpackdf.lib (it is also 23MB instead of just 240Kb for the umfpack.lib). The library is for the solver of the finite element code, so it's kind of essential. I will try to find sources for it and see if I can compile without IPO. However, this still doesn't get to the problem: this same code and library have been used by us for years, on the same computer and with the same compiler. Only the fortran source code has been adapted (without needing different external libraries). So I really don't understand why just the linking stopped working with these IPO errors.

[Steven_L_Intel1]

All I can tell you is that umfpackdf.lib was built with IPO and contains compiler intermediate code, not object code. Perhaps before you were using an older Fortran compiler of the same "vintage" as the compiler that built umfpackdf.lib, even though you believe you were using the same compiler.

I had only suggested turning off /Qipo because I had the thought that it being enabled in your build triggered the problem. but now that I think about it more, that would not be the case. What's happening now is that the compiler sees the intermediate code in the library and that forces the IPO process. There's no way to disable this because without the IPO step there's no object code to be used.