Compile Not Compile Issue Again

[sindizzy]

So I have a Parallel Studio XE 2011 in VS2010 that we have developed for at least one decade. It compiles fine and the EXEs work fine. Now I am trying to put us on a roadmap to update to the latest IFORT and then IFX.

With VS2022 and the latest intel OneAPI download (Intel® Fortran Compiler Classic 2021.12.0 [IA-32]) I have created a new solution totally from scratch.

I added project1 and added existing libs and source code and removed manifest generation and embedding. Compiled and all is good.

I added project2 and added existing libs and source code and removed manifest generation and embedding. Compiled and all is good.

I added project3 and added existing libs and source code and removed manifest generation and embedding. Compiled and now the first project will not compile.

*NO* changes to project1. No changes in code. No changes in files. No changes in switches. Just moving on to adding other projects.

The very first time I compiled this was the build log

Linking...
Link /OUT:"Release\BBB.exe" /NOLOGO /MANIFEST:NO /SUBSYSTEM:WINDOWS /IMPLIB:"BBB.lib" -qm32 "Release\BBBx.obj" <other OBJs and LIBs>
Creating library BBB.lib and object BBB.exp
BBB - 0 error(s), 22 warning(s)

The third time I compiled this was the build log

Linking...
Link /OUT:"Release\BBB.exe" /NOLOGO /MANIFEST:NO /SUBSYSTEM:WINDOWS /IMPLIB:"BBB.lib" -qm32 "Release\BBBx.obj" <other OBJs and LIBs>
libmmt.lib(log10_iface_c99.obj) : error LNK2005: __CIlog10 already defined in libucrt.lib(log10_impl.obj)
Creating library BBB.lib and object BBB.exp
Release\BBB.exe : fatal error LNK1169: one or more multiply defined symbols found
BPM - 2 error(s), 22 warning(s)

I had this issue a couple of years ago and I could not figure out the source of the problem.

Any tips, tricks, or suggestions?

[Steve_Lionel]

I notice that in the "first time" log there is no indication that an EXE was created, and what does show suggests a DLL rather than EXE. It would be interesting to see the buildlog.htm from each build and not just the output window.

The error is due to having two overlapping libraries linked in, and I might also guess that you have a mix of static and DLL linking going on leading to different sets of the same libraries being used.

[sindizzy]

There was an EXE produced the first time. In the Release folder was BBB.exe. I made sure of that.

The Buildlog.htm for my other project doesn't show that the EXE was created either. It just shows the final error count.

Linking...
Link /OUT:"Release\OCTO.exe" /NOLOGO /MANIFEST:NO /SUBSYSTEM:WINDOWS /IMPLIB:"OCTO.lib" -qm32 <OBJ files>

OCTO - 0 error(s), 24 warning(s)

 If I look in the release folder I see an OCTO.EXE file.

[Steve_Lionel]

That's not the buildlog.htm - look in the Release folder.

[sindizzy]

That is exactly where I'm getting this. I'm not posting all the fluff above the linking.

[sindizzy]

I have a total of 6 projects in this solution. Five of them produce an EXE over and over except the first one.

Well it did produce an EXE on the first two compiles.

For the first project I am looking at the switches from our older version to the new version. They are the same except the new one has -qm32 which is a switch for a 32-bit target which is fine. The only other thing I see is the OBJ and the LIB files are in a different order. Would that make a difference?

[Steve_Lionel]

You can try setting the property Linker > General > Show Progress > Show all progress messages. This will provide lots of detail in the log for which symbols are being pulled from which objects or libraries. You need to make sure that all of the projects have the same settings for the run-time library to be used, which should be the DLL form. I'm guessing that some of these are C or C++. For any static library projects, I recommend setting the property Fortran > Libraries > Disable Default Library Search Rules to Yes. 

[sindizzy]

To be clear, this particular project has 12 LIB files which as I understand are static libraries. The vendor also provides 6 FOR files for tapping into the functionality of the libs.

Anyways, this is not making any sense. As you suggested, I changed this switch to Linker > General > Show Progress > Show all progress messages. Clean the project. Rebuild the project. It works!!!??? I see the EXE in my release folder.

From my Release\Buildlog.htm file it shows tons of messages and at the bottom

     ImageHlp.lib(imagehlp.dll)
     ImageHlp.lib(imagehlp.dll)
     ImageHlp.lib(imagehlp.dll)
Finished pass 2
Failed to connect to VCTIP: 'CreateFile' failed with 2
Launching VCTIP


BBB- 0 error(s), 23 warning(s)

I'm almost starting to suspect our network is interfering with the process. Maybe as the log file is written it allows more time for the particular steps to finish (???). I was having issues with the manifest file as well, so that's why I turned it off. I could try this compile on my personal desktop away from the corporate environment.

[sindizzy]

Ok so now I go back and set Linker > General > Show Progress > Not Set

and now its compiling and I get an EXE with current timestamp.

So yeah I'm not sure what's causing the failure described above.

[sindizzy]

Back to it again. I close the solution. Open the solution. It will not compile. Same error as above.
I change the switch to Linker > General > Show Progress > Show all progress messages and still doesn't compile!

I dont get it.

[sindizzy]

Did some research relating to the error libmmt.lib(log10_iface_c99.obj) : error LNK2005: __CIlog10 already defined in libucrt.lib(log10_impl.obj) and this post suggested adding this to the switches:

Linker > Input > Additional Dependencies> libmmt.lib

I *think* this causes the compiler to search the libmmt.lib first and then other LIB files.

I have compiled and recompiled and it seems to be stable. The only thing is I am not sure why? The prior setup worked fine for years but now updating to the latest VS and Fortran compiler breaks the process. I am not sure I get why this tweak makes it work.

The switches:

/OUT:"Release\BBB.exe"
/NOLOGO
/MANIFEST:NO
/SUBSYSTEM:WINDOWS
/IMPLIB:"Release\BBB.lib" libmmt.lib -qm32 <other OBJ and LIB files>

[jimdempseyatthecove]

Your situation appears to be that libmmt.lib and libucrt.lib are mutually exclusive. (have some conflicting names)

By .NOT. placing libmmt.lib in your additional dependencies, and during link phase unresolved symbols cause the library search order to pull in libucrt.lib and in the process extract __Cllog10. Then after processing libucrt.lib, additional undefined symbols exist, this will cause the next library in library search order to be searched, and so on, until libmmt.lib is processed, and at which point you get the conflicting symbol name.

By placing libmmt.lib as an additional dependency, it is searched before the default libraries and thus satisfies the missing symbols... before the default library libucrt.lib is searched.

You (possibly) could have resolved this with adding libucrt.lib to "Ignore Specific Libraries" list.

As to using "add additional dependency" verses "Ignore Specific Libraries" this would be your preference when either method works.

Jim Dempsey

[sindizzy]

So I tried adding libucrt.lib to "Ignore Specific Libraries" list and compiled and that threw many, many exceptions so maybe I should stick with the Additional Dependencies method.

[sindizzy]

Thank you very much for the explanation. Although this does not seem to answer why our VS2010 project has none of this and has worked for a decade. I am going through go through the Properties of the VS2010 and the VS2022 projects and note the difference if any and post them here.

[andrew_4619]

"and added existing libs" I noted. Are these intel libs your libs or third party libs? What compiler level was used to build these? You should not mix things build with xe2011 and older with the latest  compiler.

[sindizzy]

@andrew_4619 ,
Good question. I have some documentation from the vendor that states the LIBs are built on Intel Visual Fortran 9.1 and written in standard FORTRAN 77.

[andrew_4619]

9.1 !!!  Other than linking problems I would expect all manner of RTL problems might exist in your build. You need updated third part libs.

[sindizzy]

Ok but like I stated we have been using these LIBs in a VS2010 project with Intel(R) Visual Fortran Compiler XE 12.0.0.104 [IA-32]. We have tested and tested and all the outputs and all results are positive. I am just trying to get ahead of this IFORT deprecation.

Plus, I work in an industry with many users so they have to cater to the lowest common denominator. The industry is also slow to adopt so changes could take years if not decades.

How would I then go about determining what other compilers are compatible with a LIB from Intel Visual Fortran 9.1?

[sindizzy]

All of the options from the VS2010 project are the same as compared to the VS2022 project. The only caveat is that some of the options only exist in one of the IDEs.

I did find one difference and it seems to be minor:

Manifest Tool>Input and Output>Embed Manifest = Yes (VS2010)  vs No (VS2022)

I am going to assume that the backend changed somehow to now require the tweak that I posted.

[andrew_4619]

So are all libraries you use built with 2022?

[sindizzy]

The vendor's LIBs are built on Intel Visual Fortran 9.1 and written in standard FORTRAN 77.