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?

[jimdempseyatthecove]

On a Solution that is linking in some old libraries used from circa IVF 9.1 I use:

This is for Debug build

Your requirements may differ.

It appears that the problem is, the default libraries changed between 2010 and 2022 combined with and additional default library (UCRT).

The "big hammer" approach would be to set Ignore All Default Libraries to Yes (Specific to empty list), build, then from the error list, one-by-one error, locate all the default libraries that contain that symbol. If you have the same symbol in multiple libraries, make note of it as either/any of these libraries could be the one you need (the other/s may need to be added to the Ignore list later). Add (one of) the found libraries to your dependency list. This should satisfy many of the missing symbols. Then repeat for the next missing symbol.

However, since you already have a way that works, why not stick with that? Save the "big hammer" for later.

Jim Dempsey

[sindizzy]

Thanks for all the info. Although I have been developing in Fortran for quite some time, the linking and LIBs has always been a mystery to me. Luckily, the one project out of six in the solution is the only one that requires LIBs from the vendor.

What I would like to do is try the solution you suggested and then the big hammer approach and see if I can learn something from it. I am documenting all the info I learn so the next guy will not have to suffer as I do.

[sindizzy]

OK the Linker > Input > Ignore Specific Libraries> libcmt.lib;libucrtd.lib was a bust. 1733 errors with most being unresolved symbol. Let me try now the big hammer approach.

[Steve_Lionel]

One of the issues may be that Microsoft did away with the static C++ library (libc) a dozen or so years ago, meaning that previously compiled objects and libraries referencing it now needed to reference different and DLL libraries. As I mentioned earlier, building a project with multiple precompiled objects and libraries can get you into trouble in the newer environment. Worse, any C/C++ code in your project needs to be recompiled because that compiler generates different code for static and DLL references. (Intel Fortran doesn't.)

I hate using "Ignore Specific Libraries", as it often causes more problems than it solves. If I were being asked to resolve this, I'd probably start with doing a "dumpbin -directives" on each of the libraries in the solution to see what they're looking for. If they're all Fortran code, then it could be helpful to set the linker option Input > Ignore All Default Libraries to Yes. Then add in, under Additional Dependencies, names of libraries that can be seen when you do a "dumpbin -directives" on a recently compiled Fortran object.

[sindizzy]

@Steve_Lionel All the LIBs from the vendor are FORTRAN 77 and compiled with Intel Fortran 9.1 and the project that references the LIBs is also all F77. No C/C++.

Let me see if I can do the dumpbin approach that you suggest. When you say ""dumpbin -directives" on a recently compiled Fortran object" I do have a VS2010 project (which is the one I am trying to upgrade) that will compile no problem. That's the one we have been using for a decade. So I would do something like "dumpbin -directives BBB.exe" to see what it's looking for correct?

[sindizzy]

Sorry, I misread your suggestion. Here is one of dumpbin /directives C:\LIB\first.lib

Dump of file C:\LIB\first.lib

File Type: LIBRARY

Linker Directives
-----------------
-defaultlib:ifconsol
-defaultlib:libifcoremt
-defaultlib:libifport
-defaultlib:libmmt
-defaultlib:LIBCMT
-defaultlib:libirc
-defaultlib:OLDNAMES

<above block is repeated 11 more times. I don't get why?>

Summary

8C .data
86D .debug$S
6CC .drectve
9F8 .rdata
3F30 .text
A38 .trace

[Steve_Lionel]

It's repeated once for each object in the library. Those all look OK. Do this again for each library in your application. 

A correction to what I wrote earlier - Microsoft removed the non-thread-safe version of the C++ static library, libc.lib. The thread-safe version (libcmt.lib) is still provided.

[sindizzy]

Ok so we have 12 LIB files from the vendor. I ran the dumpbin on all the files and they all report the same block but a different number of times. Namely this is the only thing that is output:

Linker Directives
-----------------
-defaultlib:ifconsol
-defaultlib:libifcoremt
-defaultlib:libifport
-defaultlib:libmmt
-defaultlib:LIBCMT
-defaultlib:libirc
-defaultlib:OLDNAMES

[Steve_Lionel]

OK. Next is to set the property Linker > General > Show Progress to "Show all progress messages". Do a build. If it fails, zip the buildlog.htm and attach it to a reply here so we can look at it.

[sindizzy]

So it does fail. Since this is proprietary in nature, I will post only the parts that show the failure.

Btw, the article I posted above had the same error and they suggested the following which does work for me:

Linker > Input > Additional Dependencies> libmmt.lib

      Found __CIlog10
        Referenced in libucrt.lib(cfout.obj)
        Loaded libucrt.lib(log10_impl.obj)
      Found __CIlog10_pentium4
        Referenced in libucrt.lib(log10_impl.obj)
        Loaded libucrt.lib(log10_pentium4.obj)

      Found _log10
        Referenced in libe.lib(hdpg.obj)
        Referenced in libe.lib(hdgi.obj)
        Loaded libmmt.lib(log10_iface_c99.obj)
libmmt.lib(log10_iface_c99.obj) : error LNK2005: __CIlog10 already defined in libucrt.lib(log10_impl.obj)

Unused libraries:
  C:\LIB\lib7.lib
  C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22621.0\um\x86\comctl32.lib
  C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\lib\x86\OLDNAMES.lib
  C:\Program Files (x86)\Intel\oneAPI\compiler\2024.1\lib32\ifmodintr.lib
  C:\Program Files (x86)\Intel\oneAPI\compiler\2024.1\lib32\IFWIN.LIB
  C:\Program Files (x86)\Intel\oneAPI\compiler\2024.1\lib32\ifconsol.lib
  C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22621.0\um\x86\uuid.lib

Release\BBB.exe : fatal error LNK1169: one or more multiply defined symbols found
BBB- 2 error(s), 0 warning(s)

[Steve_Lionel]

I assume you meant "doesn't work".  What I see happening from the excerpts is that there's a reference to _log10 in libe.lib that isn't resolved in libucrt.lib, but the module in libmmt that resolves it also defines _CIlog10, which has already been pulled in from libucrt.

Unfortunately, I won't be able to look into this in more detail. I will ask you to paste from the log the full filespecs of the libmmt.lib and libucrt.lib that the linker used, as I'm noting some inconsistencies between your excerpts and what I see on my system. Maybe a fresh set of eyes will help.

[sindizzy]

It does not work out of the box. With default options it does not work. Thus, my posting here in the forum.

The build log reports the above errors.

Now if I take the suggestion from another post, this option does allow it to compile without errors

Linker > Input > Additional Dependencies> libmmt.lib

Not sure what specs you want to see but here is what the linker reports:

Searching C:\Program Files (x86)\Intel\oneAPI\compiler\2024.1\lib32\libmmt.lib:

Searching C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22621.0\ucrt\x86\libucrt.lib:

[andrew_4619]

Ok you need new libraries from your vendor built with a compiler that is not nearly 20 years old. I also suggest you need 64 bit as ifx does not support 32 bit and ifort will soon be obsolete. You are looking for a easy fix cludge but that does not kick the can far down the road.

[sindizzy]

Unfortunately, the vendor probably will not upgrade their libraries. The industry is very slow to move to newer technology and they have many customers. They have to build the LIBs based on the lowest common denominator. All I can do is try to make this work so I, as an end developer, can move *my* code to a newer IDE and compiler.

As well, the industry I am in will move to 64-bit eventually but right now no. We are stuck with many legacy systems. I have a tech request with the vendor to provide two binaries: the older LIBs and new LIBs built with a new compiler and 32-bit/64-bit targets. My guess is that they will add this to their list but not get to it for several years.

In summary, I have to work with what I have.