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.
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
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.
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).
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.
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.
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.)
The output does not show signs of the original link error but numerous other link errors. It also shows compilation with 126.96.36.199 (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?
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:
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.
You still have the 17.0.2 libraries and /dbglibs specified. Don't select a "Debug" set of run-time libraries.
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.
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.
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?
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.
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.
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.
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: