- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are linking lots of libraries, at least some of which you did not build (and are C++). With C/C++, unlike Fortran, you can't just switch run-time library choices at link time. EVERYTHING needs to be built with the same libraries type, and /MTd is probably the least likely to be appropriate with external libraries.
It also appears that you are linking in code compiled with /Qipo that was compiled with different Intel compiler versions. You need to make sure that the same version is used across Fortran and C/C++.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve.
As noted I managed to get my solution built when I excluded the clp_c_interface project so it seems that it is only this project which is causing problems. It requires two libraries as specified earlier and I have rebuilt these using the same run-time library. Also neither libClp.lib nor libCoinUtils.lib requires other libraries as far as I can see:
/OUT:"C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\Clp\MSVisualStudio\v14\Debug\libClp.lib" /NODEFAULTLIB:"msvcrtd" /NOLOGO /NODEFAULTLIB
/OUT:"C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\Clp\MSVisualStudio\v14\Debug\libCoinUtils.lib" /NODEFAULTLIB:"msvcrtd" /NOLOGO /NODEFAULTLIB
This does not make any sense to me and any further pointers would be gratefully received.
Thanks, ACAR.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
libclp.lib has objects that were compiled against the non-debug C libraries (LIBCMT.LIB), but other parts of your project want the debug libraries (libcpmtd.lib) libCoinUtils.lib does not seem to request any particular libraries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How are you picking up this information Steve? I can't see that libclp is linking to anything other than the compiled source code in the project directory and I am able to link this with any of the runtime libraries I choose.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Searching libraries Searching Debug\clp_c_interface.lib: Found _CLP_SOLVE_LINEAR_PROGRAM Referenced in mp_class.obj Loaded clp_c_interface.lib(clp_c_interface.obj) Processed /DEFAULTLIB:uuid.lib Processed /DEFAULTLIB:libcpmtd clp_c_interface.lib(clp_c_interface.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:LBR' specification Searching C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\Clp\MSVisualStudio\v14\debug\libclp.lib: Found "public: __thiscall ClpSolve::ClpSolve(void)" (??0ClpSolve@@QAE@XZ) Referenced in clp_c_interface.lib(clp_c_interface.obj) Loaded libclp.lib(ClpSolve.obj) Processed /DEFAULTLIB:LIBCMT
Static libraries don't "link" to anything, but when you compile objects (that may go into a static library) they can contain linker directives that request the linker to search specific libraries. Here we see the linker describing what it sees as it loads various objects. It found clp_c_interface.obj which had references to uuis.lib and libcpmtd.lib, indicating it was compiled with /MTd. But then it finds ClpSolve in libclp.lib and that one has a directive for LIBCMT, the non-debug library, indicating it was compiled with /MT.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well this is odd because in the project properties for clp_c_interface I have set /MT. Is there some other switch that might override this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is the command line options for the project:
/GS /TP /analyze- /W3 /Zc:wchar_t /I"C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\Clp\src" /I"C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\BuildTools\headers" /I"C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\CoinUtils\src" /ZI /Gm /Od /Fd"Debug\clp_c_interface.pdb" /Zc:inline /fp:precise /D "UPPER" /D "WIN32" /D "_DEBUG" /D "_LIB" /D "_MBCS" /errorReport:none /WX- /Zc:forScope /RTC1 /Gd /Oy- /MT /Fa"Debug\" /EHsc /nologo /Fo"Debug\" /Fp"Debug\clp_c_interface.pch"
The /MT is clearly visible yet in the buildlog it appears to have been overridden...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You said earlier that you had set all the projects to use /MTd. This one doesn't.
It's possible that it isn't clp_c_interface that is referencing libcpmtd. One thing you can do is open a Fortran command prompt window, cd to the folder with clp_c_interface.obj and type:
dumpbin -directives clp_c_interface.obj
You'll see something like:
Linker Directives ----------------- -defaultlib:ifconsol -defaultlib:libifcoremt -defaultlib:libifport -defaultlib:libmmt -defaultlib:LIBCMT -defaultlib:libirc -defaultlib:svml_dispmt -defaultlib:OLDNAMES
These are all the linker directives added by the compiler. (This is for a Fortran object, but you'll see other names for a C++ object.)
Another thing I have done when this is hard to figure out is to use a file search tool (I like Agent Ransack) and search the .obj and .lib files for the library name I want to avoid - libcpmtd in this case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is the output from the dumpbin command:
Microsoft (R) COFF/PE Dumper Version 14.00.24210.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file clp_c_interface.obj
File Type: COFF OBJECT
Linker Directives
-----------------
/DEFAULTLIB:uuid.lib
/DEFAULTLIB:uuid.lib
/FAILIFMISMATCH:_CRT_STDIO_ISO_WIDE_SPECIFIERS=0
/FAILIFMISMATCH:_MSC_VER=1900
/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2
/FAILIFMISMATCH:RuntimeLibrary=MTd_StaticDebug
/DEFAULTLIB:libcpmtd
/include:?id@?$num_put@DV?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@2V0locale@2@A
/include:?id@?$numpunct@D@std@@2V0locale@2@A
/DEFAULTLIB:LIBCMT
/DEFAULTLIB:OLDNAMES
/EDITANDCONTINUE
Summary
8 .CRT$XCU
28 .bss
8 .data
250 .data$r
2E188 .debug$S
60 .debug$T
1C0 .drectve
E13 .rdata
511 .rdata$r
4 .rtc$IMZ
4 .rtc$TMZ
E0 .sxdata
7C .text$di
C274 .text$mn
9B1 .text$x
3C .text$yd
CDC .xdata$x
It appears to be using both libcpmtd and libcmt as runtime libraries?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
libcmt is the C run-time library, libcpmtd is the (Debug) C++ run-time library. I'm not sure how the C++ compiler would choose to reference both of those together, but I am not a C/C++ expert. It isn't a Fortran issue. https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx describes the various MSVC libraries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just a thought ( I have no special knowledge wrt this problem) the compiler directives for the libraries can come from directives embedded in the source file (clp_c_interface.c) as well as the compile options. It is worth checking both options.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have changed the runtime library to MTd in the properties dialog for the project. This results in:
Microsoft (R) COFF/PE Dumper Version 14.00.24210.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file clp_c_interface.obj
File Type: COFF OBJECT
Linker Directives
-----------------
/DEFAULTLIB:uuid.lib
/DEFAULTLIB:uuid.lib
/FAILIFMISMATCH:_CRT_STDIO_ISO_WIDE_SPECIFIERS=0
/FAILIFMISMATCH:_MSC_VER=1900
/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2
/FAILIFMISMATCH:RuntimeLibrary=MTd_StaticDebug
/DEFAULTLIB:libcpmtd
/include:?id@?$num_put@DV?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@2V0locale@2@A
/include:?id@?$numpunct@D@std@@2V0locale@2@A
/DEFAULTLIB:LIBCMTD
/DEFAULTLIB:OLDNAMES
/EDITANDCONTINUE
Summary
8 .CRT$XCU
28 .bss
8 .data
250 .data$r
2E188 .debug$S
60 .debug$T
1C1 .drectve
E13 .rdata
511 .rdata$r
4 .rtc$IMZ
4 .rtc$TMZ
E0 .sxdata
7C .text$di
C274 .text$mn
9B1 .text$x
3C .text$yd
CDC .xdata$x
Thanks for your suggestion Andrew. I have checked the source code clp_c_interface.ccp for compiler directives and can find none:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, now that object shows a consistent set of libraries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In my view, unless you're going to be doing debugging of the C libraries, or relying on the debug libraries extra checking of get/free, you're better off linking to the non-debug libraries all around. That said, your new log shows:
Loaded libclp.lib(ClpSolve.obj) Processed /DEFAULTLIB:LIBCMT
so you still have inconsistent settings. For the Fortran library projects it might make sense to set the property "Disable OBJCOMMENT linker directives" to Yes (under Libraries). You might have to manually name the Fortran libraries under Additional Dependencies when you link.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The c libraries are unlikely to require debugging so I can live with that. However, I must be misunderstanding some of the suggestions I have received. The background to this is that I was simply migrating a fully working solution from a previous version of VS and Intel Fortran. I have understood from your advice that the runtime libraries should be consistent (identical) for the projects involved in the solution.I have done this but as we have seen /MT and /MTd leads to errors. I cannot therefore see where I have any inconsistent settings. Are you now suggesting that I change the runtime libraries for the c libraries to /MT whilst leaving the fortran objects as /MTd? As always, thanks for your continued assistance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Consistent means consistent. Use all /MT (or better, all /MD). I am not aware of anything in a new version that would trigger this difference, though you started this thread with a somewhat different issue. Also, your inconsistencies seem to be all on the C/C++ side.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am gratified to see Steve L. make a direct and clear statement regarding the use of "debug libraries" in #38. In my experience, in which I have heavy exposure to character mode applications, I have never needed to use the "debug" versions of the Fortran, C/C++ or OS libraries. Consequently, I have run into the multiple library syndrome only in those instances where I had to use a third party library or DLL for which no source code was provided, and that library or DLL had a dependence on the "debug" RTLs.
As Steve said, don't use /MTd or /MDd unless you have a definite reason to do so. Likewise, if you provide a library or DLL to users, don't build it using /MTd or /MDd. Furthermore, in most situations it is preferable to use /MD instead of /MT, especially if your application uses MKL routines. I have seen some simple MKL-dependent programs generate an 80 MB EXE with /MT and just 1 MB with /MD.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am still struggling to understand where the problem lies. I have a solution which I have linked with the /MTd RTLs and it works fine. I then add my clp_c_interface.cpp which requires two libraries which I have access to the source code and have linked with the same /MTd RTLs. I do not therefore see how there can be a conflict yet one appears.
I have taken the suggestion to link all parts of my project against the /MD RTLs. It again fails seemingly with conflicts between libifcoremd and libifcoremt, amongst others. I have attached the buildlog for perusal.
If there is something I can do to get rid of this then do please advise me - thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Acar, here we are at response #40 in this thread, apparently stuck in a loop. It is perhaps time to re-evaluate your position regarding a reproducer (see #2). If there are concerns regarding publishing your sources, you may either prune the code to make the concerns go away before posting, or provide the code as-is to Intel personnel only.
If you decide to share a reproducer, I suggest that you break up the sources into one Zip per library or application and attach the zips to your reply. Alternatively, you can compile the user libraries yourself (using /MD) and provide only the pre-built libraries, plus the sources for the application that is to be built with these libraries, and a few notes to guide the building process.
Sometimes, it helps to break the log jam if more than one toolset can be tried on the problem, so attempting to rebuild with an older or newer toolset is a low-cost effort way of troubleshooting.
[Added a few minutes later] I have looked at your latest BuildLog.htm. There are only two missing external symbols: CrtDbgReportW and invalid_parameter. The "debug" libraries/DLLs msvcrtd and msvcurtd provide these symbols; the non-debug libraries msvcrt and msvcurt do not. The missing symbols are referenced in your libraries libclp.lib, libCoin_utils.lib and clp_c_interface.lib. If you wish to use the "release" dynamic RTL libraries/DLLs, as is consistent with the /MD option, you probably need to rebuild these three libraries from sources using /MD.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
See my earlier suggestion to use a file searching tool to search the .obj files for the conflicting library name.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page