Caused by having a CEILING intrinsic call in the code? (yes, i commented it out and it is fine).
(shown above) raises a suspicion that some objects were compiled with /MT and some with /MD, or that inconsistent library choices were made.
and I guess I recompile the c libraries with consistent switches -- found one that was compiled with /md in release mode.
in the mean time have implemented a work around for the CEILING call though I guess I could try some other ignores.
until i can recompile the c libraries, i've gone with all "debug" versions of the libraries. and that seems to work.
Nothing wrong with that; /MD simply specifies linking against DLL libraries (e.g., MSVCRT.LIB). The D in /MD does not mean "debug".
If /MT were used instead, that would indicate linking against LIBCMT.LIB.
/MD is Multithread DLL. If you want the Debug version, that's /MDd.
When you have C code, it is not safe to ignore libraries to paper over a mismatch, as the C compiler actually generates different object code depending on which library choice was made for the project. If it's just Fortran code, then it doesn't matter as much.
It appears I still have to compile these c libraries (someone else compiled them) and make sure they are using the same switches. In the meantime, i went to the debug versions of these and it added considerable to the test suite run.
And I probably threw in the ignore x.lib comment somewhere "right before release" which is when things tend to come together. (and then never investigated it).