This document describes a minor problem that may be encountered when using the DLL versions of the NAG C Library. This difficulty results from a change to the Microsoft linker to support .NET. You will only find this problem if you use a version of Microsoft C++ that is different from the one used to implement the library, access from all other environments is unaffected. This problem does not affect the static libraries.
The DLL files in the following NAG C Library implementations were created using the Microsoft Visual C++ Release 8.0 linker and C run time libraries (part of Visual Studio 2005).
In Visual Studio 2005 Microsoft have introduced the concept of side-by-side assemblies and manifest files. The linker creates the manifest file for the DLL. This is an XML file that sets out the dependencies of that DLL on other DLLs, in this case the Microsoft C run time DLLs.
Although the NAG C DLL is not a side-by-side assembly, Microsoft still requires that manifest files are compiled into DLLs. If this is not done it is not possible to link to the DLL.
The manifest file that is compiled into the NAG C DLLs creates a dependency on version '8.0.50608.0' of the C run time library. The redistributable versions of these Microsoft Visual C++ Release 8.0 run time libraries are installed in the same folder as the NAG DLLs, so even if you do not already have the required C run times you can use the NAG C Library.
If you are developing code with exactly the same version of Microsoft Visual C++ that was used to implement these libraries, there is no problem. The exact version numbers of C compiler and linker used in the above implementations are -
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 Microsoft (R) Incremental Linker Version 8.00.50727.42
However, if you are using a different version of Microsoft Visual C++ to compile code to call the DLL versions of the NAG C library, your code may depend on a different version of the Microsoft C run time library. This results in an executable that includes two different C run time libraries.If this is the case, you should avoid -
- mixing output from your code with output from the C Library
- reading data from the same file in your code and the C Library
An example of this type of problem may be seen in the NAG example program c06pfce.c, which writes a title using printf and calls nag_gen_complx_mat_print_comp (x04dbc) to output a matrix. The title is written after the matrices printed by the NAG C Library. This is caused by having two different C run time libraries linked to the executable, using buffered output which is flushed independently by each run time library.
In the future NAG C Library examples will include an explicit flush to force out the title in the right place. (Unfortunately it was not possible to make this change in all implementations of Mark 8.) You can avoid this problem in your own code by putting in "fflush" statements in appropriate places. Indeed, the newly reissued CLW6A08DA and CLW3208DB implementations contain example program source with the necessary "fflush" statements.
Code that relies on reading the same input file from C code and also via a NAG C Library function will not work as the current file pointer will not be shared by the two run time libraries. This may be seen in the failure of the NAG C Library example program e04nrce.c, which reads data for the C example and then options for the NAG C Library from the same file. When the function nag_opt_sparse_convex_qp_option_set_file (e04nrc) is called to read the options that follow the first set of data, the file pointer in the C run time library linked to the NAG C Library is at the beginning of the file and not at the beginning of the options and the call fails.