Compiler 14 problems.

[lklawrie]

me:

I'm also getting an unresolved external - _intel_new_feature_init referenced in function MAIN_.  is this because I'm using VS2008 or what?

Steve reply:

You are not linking to the correct run-time libraries. Check the library paths you are using. I'd also ask that you start new threads on problems, or use Intel Premier Support.

Me again:  I did nothing different than I usually do with the intall -- let it overwrite the defaults for the compiler.  Here is the library path it appears to be using:

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

[Steven_L_Intel1]

Is this a 32-bit or 64-bit build? The symbol name is for 32-bit but you are reporting libraries for 64-bit.

Please set the property Linker > General > Show Progress > SHow All Progress Messages. Redo the link, then attach a ZIP of the build log to a reply here.

[lklawrie]

Should be 64 bit -- has been in the past.  I have a different setup for building for 32 bit.  The project is generated by cmake -- i didn't regenerate before using the new compiler.

I did not watch the install of the new compiler -- just let it install.

[TimP]

I've seen errors such as the one quoted at the top of the thread, which were corrected by rebuilding all objects and linking with the new compiler.  If the main .obj is rebuilt with the new compiler, it won't link correctly against old run-time libraries.

In order to help avoid such problems, I try to remove all references to Intel compilers from the Windows PATH settings, so that only the paths set by compilervars.bat or by selecting the compiler in Visual Studio will be present.  As you probably know, changing your Windows PATH settings doesn't take effect until reboot.

If you return to the older compiler version, you will need to rebuild those .obj again.

[lklawrie]

The first thing I did when I put on this compiler was to "clean" the solution and rebuild.  There is no "main.obj" -- the main program is in Fortran and is named.  Unless the install puts things in Windows Path -- I have not. 

And then there is still the problem of the ICE in one of the modules.  I don't know if that is a new ICE or would exist in the Issue #0000698745 with opt=2 (which I think was in there).

[lklawrie]

Cleaned the solution, removed the windows env variable that referenced the 13 compiler (maybe there were others), rebooted and it still didn't help.

Back to v13, hoping I can get it to work.

[Steven_L_Intel1]

I think you're still pulling in  32-bit object in the link.

[lklawrie]

Well, it didn't used to -- does the buildlog tell you anything?  Or at least it didn't used to be a problem.  It says it's x64 in VS.  There are two c modules that get compiled in -- I didn't change that compiler.

[Steven_L_Intel1]

If you sent me the build log, it would help. You might want to verify that the C project is also x64 in your solution configuration (look at the Configuration Manager). It is possible to unintentionally get a mix of x64 and Win32 projects in a configuration. Are you using Intel C++ or MSVC? (If MSVC, then that's not the problem.)

[lklawrie]

I did -- it's attached in earlier message in this thread -- zip file with verbose on -- as suggested.  The C projects are using MSVC, I believe.  As I said -- this configuration has been working (I believe) with the v13 compiler.  Built from CMake.

[lklawrie]

Well, I did attach it -- about the 3rd message in this thread, but I don't see it.  Will try again.  I see -- I forgot to hit start upload.

[lklawrie]

All files in the project are x64.  See attached.

[Steven_L_Intel1]

You have told the linker explicitly to add the 13 compiler's LIB folders, and it found those before it found the new ones. Check your Linker properties for General > Additional Library Directories and remove those.

[TimP]

lklawrie wrote:

Well, I did attach it -- about the 3rd message in this thread, but I don't see it.  Will try again.  I see -- I forgot to hit start upload.

This appears to confirm the suspicion that you are attempting to link XE2013/"ifort 13.1" libraries rather than "XE2013 SP1/14.0" libraries.

[lklawrie]

What Steve said appeared to have fixed it -- I just blanked that part of the linker -- I don't know why they got added unless some part of the CMake project did that? Why doesn't the install remove those libraries -- or maybe it did.

[Steven_L_Intel1]

No, the install doesn't remove the older version. That happens only if you install an update and selected to replace the earlier update. If it had removed the libraries, you would not have seen an error here as the linker would have just skipped the old folder.

[lklawrie]

I'm sorry, but I assumed that's what install I did.  That's what I always select in the install.  Which has worked until now -- when the compiler number changed or you added SP1 to the folder name.  Well, it will make it easy to go back to V13 last update if it didn't replace it.

[Steven_L_Intel1]

I understand the confusion. The "SP1" naming makes it sound like an update, but it's really a whole new version. Marketing....

[lklawrie]

So we can blame Marketing.... who probably don't read this forum?

[Steven_L_Intel1]

Yes to both, but I will pass on your comments.