Linker Conflict libmmt and libcpmtd

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

 

58 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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?

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.

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).

Steve (aka "Doctor Fortran") - Retired from Intel

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.

Steve (aka "Doctor Fortran") - Retired from Intel

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.)

Steve (aka "Doctor Fortran") - Retired from Intel

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

Attachments: 

AttachmentSize
Downloadapplication/zip BuildLog.zip108.4 KB

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?

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.  

Attachments: 

AttachmentSize
Downloadapplication/zip BuildLog.zip147.97 KB

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)".

 

Steve (aka "Doctor Fortran") - Retired from Intel

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.

Attachments: 

AttachmentSize
Downloadapplication/zip BuildLog.zip96.22 KB

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

Steve (aka "Doctor Fortran") - Retired from Intel

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.

Attachments: 

AttachmentSize
Downloadapplication/zip BuildLog.zip98.32 KB

Quote:

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.

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.

 

Attachments: 

AttachmentSize
Downloadapplication/zip BuildLog.zip129.53 KB

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?

Quote:

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.

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:

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.

 

Attachments: 

AttachmentSize
Downloadapplication/zip BuildLog.zip150.52 KB

I have now rebuilt the solution using the /MTd option.  Some of the previous errors/warnings have now gone but I am still getting some issue - see attached buildlog.

Attachments: 

AttachmentSize
Downloadapplication/zip BuildLog.zip149.26 KB

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++.

Steve (aka "Doctor Fortran") - Retired from Intel

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.

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.

Steve (aka "Doctor Fortran") - Retired from Intel

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.

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.

Steve (aka "Doctor Fortran") - Retired from Intel

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?

 

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...

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.

Steve (aka "Doctor Fortran") - Retired from Intel

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?

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.

Steve (aka "Doctor Fortran") - Retired from Intel

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. 

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:

// clp_interface.cpp : Defines the entry point for the static library application.

//

 

#include <windows.h>

#include <stdio.h>

#include "ClpSimplex.hpp"

 

#define EXTERN extern "C" {

#define EXTEND }

#define INTEL_BINDING __cdecl

 

#ifdef UPPER

#define clp_solve_linear_program CLP_SOLVE_LINEAR_PROGRAM

#define clp_usercallback CLP_INTERFACE_MODULE_mp_CLP_INTERFACE_CALLBACK_FUNCTION

#else

#define clp_solve_linear_program clp_solve_linear_program_

#endif

 

EXTERN int INTEL_BINDING clp_usercallback(int *caller);

EXTEND

 

EXTERN int INTEL_BINDING clp_solve_linear_program(char *infile, int *opt, int *nproc, char *outfile, int len1, int len2)

{

   char *Input_Filename;

//   int   Optimiser;

//   int   Number_of_Processors;

   char *Output_Filename;

 

#define STRNCPY1(y,x,l) {int ic,il; \

for (il=l-1; x[il] == ' ' && il >= 0; il--) { } \

for (ic = 0; ic <= il; ic++) { \

y[ic] = x[ic]; \

} \

y[il+1] = '\0'; \

}

 

#define clp_output MP_CLASS_mp_CLP_OUTPUT

   

   extern void clp_output(double*,double*);

 

   Input_Filename = (char *) malloc( (len1+1) * sizeof(char));

   STRNCPY1(Input_Filename, infile, len1);

 

   Output_Filename = (char *) malloc( (len2+1) * sizeof(char));

   STRNCPY1(Output_Filename, outfile, len2);

  

   ClpSimplex  model;

  

   int status;

  

   status=model.readMps(Input_Filename,true);

 

   if(status=0);

 

  {

 

 ClpSolve solvectl;

 

 solvectl.setSolveType(ClpSolve::useBarrier);

   

 solvectl.setPresolveType(ClpSolve::presolveOff);

   

 model.initialSolve(solvectl);

 

 

 

 //double * columnPrimal = model.primalColumnSolution();

 

 //double * rowDual = model.dualRowSolution();

 

 //clp_output(&columnPrimal[0:10],&rowDual[0]);

 

 

 double * columnObjective = model.objective();  

 

 double objective = model.objectiveValue();    

 

 FILE *fp=fopen(Output_Filename,"w");

 

 int iRow;

 

 int numberRows = model.numberRows();

 

 int iCol;

 

 int numberColumns = model.numberColumns();

 

 double value;

 

 double * columnPrimal = model.primalColumnSolution();

 

 double * rowDual = model.dualRowSolution();

 

 char * columnName;

 

 char * rowName;

 

 double * primalColumnSolution = model.primalColumnSolution();

   

 double * dualRowSolution = model.dualRowSolution();

 

 double * columnLower = model.columnLower();

 

 double * columnUpper = model.columnUpper();

 

 fprintf(fp,"%s\n","Primal Solution");

 

 for (iCol=0;iCol<numberColumns;iCol++) {

     

 value = primalColumnSolution[iCol];

 

 columnName = CoinStrdup(model.columnName(iCol).c_str());

 

 fprintf(fp,"%s %e\n",columnName,value);

}

 

 fprintf(fp,"%s\n","Dual Solution");

 

 for (iRow=0;iRow<numberRows;iRow++) {

   

 value = rowDual[iRow];

 

 rowName = CoinStrdup(model.rowName(iRow).c_str());

 

 fprintf(fp,"%s %e\n",rowName,value);

  }

 

 fclose(fp);

   

 free(Input_Filename);

   

 free(Output_Filename);

  }

 

return status;

}

 

}

Ok, now that object shows a consistent set of libraries.

Steve (aka "Doctor Fortran") - Retired from Intel

Indeed and the logic might be to change the runtime libraries for the other projects in this solution to /MTd.  If I do this then I get another conflict as shown in the attached buildlog.

 

Attachments: 

AttachmentSize
Downloadapplication/zip BuildLog.zip149.26 KB

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.

Steve (aka "Doctor Fortran") - Retired from Intel

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.

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.

Steve (aka "Doctor Fortran") - Retired from Intel

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.

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.

Attachments: 

AttachmentSize
Downloadapplication/zip BuildLog.zip94.34 KB

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. 

See my earlier suggestion to use a file searching tool to search the .obj files for the conflicting library name.

Steve (aka "Doctor Fortran") - Retired from Intel

I have no objection whatsoever to sending my code to someone at Intel (apart from the mild embarrassment I will have in an expert viewing the code of a mechanical engineer).  Before I do this though I will take Steve's suggestion and look deeper into the .obj files to see if this brings up the solution.  I'll report back in due course.

This isn't something appropriate for Intel support. You have all the tools at hand necessary to determine the cause and fix the problem. It isn't a shortcoming in the Intel product. Searching the .obj files (and .lib files) for the offending library name will get you 90% of the way there.

I also want to elaborate on my earlier remarks regarding debug libraries. There's nothing wrong with using debug libraries while building debug configurations, but it can get messy if you are pulling in static libraries you didn't build. One big advantage of the debug libraries, that I alluded to before, is that the C library's get/free adds consistency checks with the debug library that can help you locate heap corruption, double frees, etc.

I will also point out that the debug libraries are NOT redistributable, so you can't (or shouldn't) build an application linked to the debug libraries and then run it on a system where the development product is not installed. This is especially noticeable if you are linking to debug DLL libraries.

Intel Fortran, unlike the various C/C++ compilers (Intel and MS), doesn't generate different code depending on your choice of libraries. This is why it is often a good idea to build Fortran static libraries with the "Disable OBJCOMMENT directives" option enabled so that the objects in the library don't request any particular set of libraries. This does mean that the executable project must pull in the necessary libraries, and if it's not a Fortran main program you have to manually name the needed Fortran run-time libraries when linking.

Steve (aka "Doctor Fortran") - Retired from Intel

I have taken Steve's suggestion from the following topic:

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo...

This seems to have removed all the conflicts and I now get an executable for my solution but it does not 'execute'!

Any suggestions regarding this - I've attached the buildlog?

Attachments: 

AttachmentSize
Downloadapplication/zip BuildLog.zip60.14 KB

Please describe exactly how you attempted to "execute" and what you observed after that. Did you see any error messages? Did the program hang (check with the Task Manager or the tasklist command line utility).

I double click the executable and absolutely nothing happens - no error messages, no hanging (no evidence of the process in the Task Manager).

The program does run in debug mode - bizarre!!

Run the program from a command prompt window and see if you get any messages.

Steve (aka "Doctor Fortran") - Retired from Intel

Absolutely nothing when I attempt to run the program from the command prompt...

Does this program look for input files and exit if it doesn't find any?

Steve (aka "Doctor Fortran") - Retired from Intel

Pages

Leave a Comment

Please sign in to add a comment. Not a member? Join today