Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
118 Views

Linker Conflict libmmt and libcpmtd

Hello,

I recently migrated to the latest VS and Intel fortran compiler.  I am getting the following errors:

Severity    Code    Description    Project    File    Line    Suppression State
Error        error LNK2005: _powf already defined in libmmt.lib(powf_iface_c99.obj)        libcpmtd.lib(locale.obj)        

Any advice on overcoming this would be greatly appreciated.

Many thanks,

ACAR

 

0 Kudos
57 Replies
Highlighted
Employee
102 Views

Which specific versions of Visual Studio and Intel Visual Fortran are you using?

I haven’t been able to synthesize this. Could you perhaps provide a reproducer?

0 Kudos
Highlighted
Beginner
102 Views

Hi Kevin D,

Thanks for getting in contact.  The Intel compiler is 2017 and the VS version is:

Microsoft Visual Studio Professional 2015
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.6.01055

I appreciated the value of a repeater program but having tried this in the past and spent many hours on it I am reluctant to go down this route if at all possible.

Many thanks,

ACAR.

0 Kudos
Highlighted
Black Belt Retired Employee
102 Views

What triggered the error was that libmmt.lib was searched and symbol _powf was pulled in from it. Later, some other reference caused locale.obj from libcpmtd.lib to be pulled in, and this also defined _powf. 

Looking at what is in locale.obj, it seems to be supporting a bunch of C++ things but I really don't understand why _powf is in there. I do note that you seem to have a mix of debug and non-debug libraries, which can cause problems. First make sure that your Fortran and C++ project settings have the same choice for use of run-time libraries (static vs DLL, debug vs. non-debug).

0 Kudos
Highlighted
Black Belt Retired Employee
102 Views

If using consistent library settings doesn't resolve the issue, try changing both projects to use DLL libraries. An alternative is to name libcpmt.lib explicitly in the Linker > Additional Dependencies property of the executable project so that it gets linked in first.

0 Kudos
Highlighted
Beginner
102 Views

Thanks for your input Steve and apologies for the long delay in responding.  I have checked for consistency of the run-time libraries, and I have added libcpmt.lib explicitly as suggested.  Neither of these approaches help and I still have the LNK2005 error.  Any further ideas would be gratefully received.  ACAR.

0 Kudos
Highlighted
Black Belt Retired Employee
102 Views

Please do this to help us help you. Change the project property Linker > General > Show Progress to "Show all progress messages". Do a Rebuild (not just Build) of the solution. Create a ZIP of the buildlog.html and attazh the ZIP to a reply here. (Please don't just paste it.)

0 Kudos
Highlighted
Beginner
102 Views

I have attached the buildlog as requested.  Many thanks in anticipation of your help Steve. 

0 Kudos
Highlighted
Employee
102 Views

The output does not show signs of the original link error but numerous other link errors. It also shows compilation with 17.0.4.210 (update 4) compiler but apparent hard linkage to the update 2 compiler/libs, i.e. compilers_and_libraries_2017.2.187.

The numerous link errors relate to using /NODEFAULTLIB  (i.e. Linker > Input > Ignore All Default Libraries). Was there something that prompting setting that?

0 Kudos
Highlighted
Beginner
102 Views

Apologies, I have changed the settings so much that I don't really know where I stand.  If I set /nodefaultlib then I get the errors mentioned previously and I have attached the buildlog.  

0 Kudos
Highlighted
Black Belt Retired Employee
102 Views

A couple of things stand out. First, as Kevin notes you have an explicit /libpath setting for an older version of the Intel libraries. This should be removed. 

Second, you're building a Debug configuration but it is evident that at least some of the third-party libraries you're linking against are built with explicit references to the non-debug MSVC libraries. Yes, the linker tells you to use /IGNORELIB but you should never do this as a first solution.

My advice is:

  1. Remove the old-version Intel library from your additional library paths. (This may resolve the IPO warnings as well)
  2. Set the project property Fortran > Libraries > Use Run-Time Libraries to "Multithread DLL (/MD)" - not any of the Debug settings. If that gives you other issues, try "Multithreaded (/MT)".

 

0 Kudos
Highlighted
Beginner
102 Views

I have removed the old versions of the Intel libraries.  This made no difference (but at least tidies things up)

If I switch to Multithread DLL (/MD) then I get an issue with clp_c_interface since this references a number of libraries that seem to have been compiled with Multi-threaded Debug (/MTd).

I am attaching a further buildlog for your inspection.

Thanks for your continued help.

0 Kudos
Highlighted
Black Belt Retired Employee
102 Views

You still have the 17.0.2 libraries and /dbglibs specified. Don't select a "Debug" set of run-time libraries.

0 Kudos
Highlighted
Beginner
102 Views

I thought I had removed the pointer to the old libraries - unless they are hiding somewhere else?  I have switched to a non-debug set of runtime libraries for EFESYS and have attached the buildlog.  In reality though I need the ability to debug the project.

0 Kudos
Highlighted
Black Belt
102 Views

acar wrote:
In reality though I need the ability to debug the project.

Typically, you do not need to link with the debug versions of the Fortran RTL when debugging your own code.

Similarly, if you are using mature and tested libraries such as Mosek, DonLP2, COIN, etc., you do not need debug versions of those libraries. In fact, having debug symbols for such libraries makes it easier to enter and get stuck in a swamp of symbols whose role may not even be known to users.

If you do suspect a bug in a library routine, it is usually sufficient to document the call, provide input argument values, and let the author/proprietor of the library worry about fixing their code.

0 Kudos
Highlighted
Beginner
102 Views

After having to stop attempting to migrate my software to the latest versions on the compiler, I have had another go.  I have removed one of the libraries that I think might have been causing some of the issues and now get only two unresolved symbols - see buildlog (attached).

Any assistance with sorting this out would be gratefully received.

 

0 Kudos
Highlighted
Black Belt
102 Views

Your buildlog.htm is a big monster, with thousands of warnings and remarks, none of which are relevant to the focal problem: linking errors; specifically, two missing external references.

It would help if you turned off compiler warnings for the duration. Later, after you are able to link successfully, you can turn those warnings on again to help debug your code.

If you are using a mix of the new and Microsoft C standard libraries, you may run into incompatibility problems. For example, see https://msdn.microsoft.com/en-us/library/kxsfc1ab.aspx regarding removal of support for Fortran style exponents in the strings passed to the C function strtod(). Did you build your triangle.lib using a different version of VC than the version used to produce other objects/libraries?

acar wrote:
 I have removed one of the libraries that I think might have been causing some of the issues and now get only two unresolved symbolsI have removed one of the libraries that I think might have been causing some of the issues and now get only two unresolved symbols 

Well, that is to be expected. You cannot build and EXE or DLL without using all the needed libraries.

0 Kudos
Highlighted
Beginner
102 Views

I removed a project which was using some libraries which may have been compiled/linked using an older version of VC and I removed reference to this in my main project.  I then sent you the buildlog.  The project triangle is compiled and linked as part of my solution so I guess (?) it is using the most uptodate libraries.  

0 Kudos
Highlighted
Beginner
102 Views

Having returned to try and solve this issue I switched all projects to Multithreaded (/MT) and rebuilt the lot.  My solution now compiles and links with no problem.  Thanks for everyones help with this.

0 Kudos
Highlighted
Beginner
102 Views

Following the success of getting my solution to compile and link using the /MT option throughout I then added back the CLP routines.  I have an interface clp_c_interface.f which calls two static libraries libclp.lib and libcoinutils.lib.  I have rebuilt these libraries using the /MT option:

/GS /analyze- /W3 /Zc:wchar_t /I"..\..\..\..\CoinUtils\src" /I"..\..\..\..\BuildTools\headers" /ZI /Gm /Od /Fd"Debug\libClp.pdb" /Zc:inline /fp:precise /D "WIN32" /D "_DEBUG" /D "_LIB" /D "_CRT_SECURE_NO_WARNINGS" /D "_CRT_SECURE_NO_DEPRECATE" /D "_VC80_UPGRADE=0x0710" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /RTC1 /GR /Gd /Oy- /MT /Fa"Debug\" /EHsc /nologo /Fo"Debug\" /Fp"Debug\libClp.pch" 

However, when I attempt to build my solution EFESYS it fails.  I have attached a zipped version of my buildlog.  There are some warnings which appear to indicate a mismatch between MT and MTd:

Severity Code Description Project File Line Suppression State
Warning warning #11087: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\libcpmt.lib: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' does not match value 'MTd_StaticDebug' in C:\RMA\Programs\EFE_V1.0\EFE\Debug\clp_c_interface.lib. ipo
 
I am not sure how this is happening since clp_c_interface.lib is linked using the MT option and not the MTd option.
 
Could I please beg a little more of your time for some further advice?
 
Many thanks ACAR.

 

0 Kudos