Ignore the linker error - on closer inspection libmmd.lib refers to the debug Fortran runtime which is being pulled in by an external library, so I should rule this out first. Out of interest, inconsistent floating point model settings (fast, precise, strict) across libs can produce this same error.
Regarding DFAContentModel.cpp, l.1050, the important question remains: is the natural log correct, or should it be log base 2? I'd be very grateful if someone could answer this! Thanks in advance. From: Martin, Paul Sent: 27 September 2014 00:51 To: 'c-users@xerces.apache.org' Subject: Xerces log function call in DFAContentModel.cpp Hello, I am linking Xerces 3.1.1 (static lib, release mode, VC++ 12) with a DLL that also contains Fortran code. This results in the following link error: xerces-c_3.lib(DFAContentModel.obj) : error LNK2005: _logf already defined in libmmd.lib(libmmd.dll) The cause is a duplicate symbol, logf, in both the Fortran and C++ runtme library. The call occurs in Xerces\source\src\xercesc\validators\common\DFAContentModel.cpp, l.1050. The usual workaround for Fortran & C++ runtime name conflicts is to ignore one or other library. Ignoring libcmt (C++ static rutime) seems to work most of the time, but it does not solve the problem here. Interestingly, I have seen the same issue occur in debug builds in the past, and one successful workaround was to enable inlining. This time the issue has cropped up in a release build, where inlining is already enabled (using /Ob2 - auto). On inspecting the Xerces code more closely, I noticed that the log call in DFAContentModel.cpp is preceded by a comment mentioning "a binary search to locate the leaf in the sorted list of places (M times log(N) testing operations Ts)". If this is a binary tree I would expect it to use log2, not ln, and indeed when I link against Xerces using log2 in place of ln, the build succeeds. I get the feeling I'm just buying time until the next name clash, but was the use of ln here a mistake? With log2 my code runs correctly and the performance is fine. Comments gratefully received. Paul '************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. **************************************************************************************
