Unresolved external when linking to odbc libs - by thomas_schmidt

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


10
0
Sign in
to vote
ID 1039102 Comments
Status Closed Workarounds
Type Bug Repros 4
Opened 11/25/2014 1:21:26 AM
Access Restriction Public

Description

I'm trying to compile GDAL (http://www.gdal.org/) with VS 2015 Preview. Currently I'm stuck with an unresolved external from odbccp32.lib, obviously resulting in the crt changes in the 14.0 compiler.

Here's the message:

odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol __vsnwprintf_s referenced in function _StringCchPrintfW

I compiled from the VS2014 x86 Native Tools command prompt. The lib comes from 

C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x86

This SDK must have been installed with VS 2015 Preview (or VS 2014 CTP).

My impression is odbc*.lib relies on old CRT features and has to be updated. The same sources (slightly changed makefile) have compiled with VS 2013.
Is there a newer SDK version or how can I solve the problem?
Sign in to post a comment.
Posted by James [MSFT] on 4/29/2016 at 2:56 PM
Hello,

It appears that my original reply has been misinterpreted; I think it was less clear than it could have been. To attempt to clarify my explanation:

This is a breaking change in the Universal CRT, used by Visual Studio 2015 and Windows 10. Mixing-and-matching object files compiled with different major versions of the Microsoft C and C++ runtime library headers is not supported. For several releases, the C++ Standard Library headers have enforced this via a #pragma detect_mismatch, which causes link errors when mixing-and-matching is detected. The CRT headers have not enforced this, but it is nonetheless not supported. In general, in cases where you want to build your own library that can be used by programs built using different versions of Microsoft Visual C++, the best way to do this is to build your library into a DLL, to encapsulate its dependencies on the particular version of the Visual C++ libraries on which it depends.

This breaking change is a result of some of the redesign work that went into the Universal CRT. To provide partial link compatibility with object files (and libraries) compiled with older versions of the Microsoft C Runtime headers, we provide a library, legacy_stdio_definitions.lib, with Visual Studio 2015. This library provides compatibility symbols for most of the functions and data exports that were removed from the Universal CRT. The set of compatibility symbols provided by legacy_stdio_definitions.lib is sufficient to satisfy most dependencies, including all of the dependencies in libraries included in the Windows SDK. However, there are some symbols that were removed from the Universal CRT for which it is not possible to provide compatibility symbols like this. These symbols include some functions (e.g., __iob_func) and the data exports (e.g., __imp___iob, __imp___pctype, __imp___mb_cur_max).

If you have a static library that was built with an older version of the C Runtime headers, we would recommend the following actions (in this order):

(1) Rebuild the static library using Visual C++ 2015 and the Universal CRT headers to support linking with the Universal CRT. This is the fully supported (and thus best) option.

(2) If you cannot (or do not want to) rebuild the static library, you may try linking with legacy_stdio_definitions.lib. If it satisfies the link-time dependencies of your static library, you will want to thoroughly test the static library as it is used in the binary, to make sure that it is not adversely affected by any of the behavioral changes that were made to the Universal CRT (see https://msdn.microsoft.com/en-us/library/bb531344.aspx#BK_CRT for details).

(3) If your static library’s dependencies are not satisfied by legacy_stdio_definitions.lib or if the library does not work with the Universal CRT due to the aforementioned behavioral changes, we would recommend encapsulating your static library into a DLL that you link with the correct version of the Microsoft C Runtime. For example, if the static library was built using Visual C++ 2013, you would want to build this DLL using Visual C++ 2013 and the Visual C++ 2013 libraries as well. By building the library into a DLL, you encapsulate the implementation detail that is its dependency on a particular version of the Microsoft C Runtime. (Note that you will want to be careful that the DLL interface does not “leak” details of which C Runtime it uses, e.g. by returning a FILE* across the DLL boundary or by returning a malloc-allocated pointer and expecting the caller to free it.)

We understand that this breaking change has been problematic for some of our customers, and we are continuing to investigate opportunities for improving the situation, both with the versions of the libraries that have been released and with future versions of the libraries. What I have described thus far is the current (and foreseeable) state.

Sincerely,

James McNellis
Visual C++ Libraries
james.mcnellis@microsoft.com
Posted by BOFHRAF on 1/6/2016 at 5:00 AM
The problem still exists in Visual Studio 2015 Update 1!

Please fix existing bugs instead of introducing new stuff with new bugs.

My "developer experience" is really bad...
Posted by pravk19 on 8/19/2015 at 9:30 AM
error LNK2001: unresolved external symbol __imp___iob
error LNK2019: unresolved external symbol __imp___pctype referenced in function _
error LNK2019: unresolved external symbol __imp____mb_cur_max referenced in function


unresolved external symbol __imp___iob , __imp___pctype, __imp____mb_cur_max in Visual studio 2015

unable to build application in VS 2015
Posted by pravk19 on 8/19/2015 at 9:29 AM
error LNK2001: unresolved external symbol __imp___iob
error LNK2019: unresolved external symbol __imp___pctype referenced in function _
error LNK2019: unresolved external symbol __imp____mb_cur_max referenced in function


unresolved external symbol __imp___iob , __imp___pctype, __imp____mb_cur_max in Visual studio 2015

unable to build application in VS 2015

Please help
Posted by James [MSFT] on 3/16/2015 at 1:18 PM
Hello,

Thank you for reporting this issue. This problem is a result of some of the redesign work that went into the runtime libraries for Visual Studio 2015. As a workaround for the problem, please link with legacy_stdio_definitions.lib. This library has external definitions of most of the symbols that the Windows SDK (and many other libraries) require but which are not present in the new runtime libraries. This library should resolve most link issues.

There are several libraries in the Windows 8.1 SDK that have additional dependencies that are not satisfied by this legacy_stdio_definitions.lib library. The final release of Visual Studio 2015 will include an updated Windows SDK that resolves remaining issues. Additionally, the legacy_stdio_definitions.lib library is currently missing the __imp_-prefixed aliases required by some libraries; these will be added in a future builds of Visual Studio 2015.

We are continuing to work on improving the developer experience for future builds of Visual Studio 2015.

Please feel free to contact me directly via e-mail if you have further questions.

Sincerely,

James McNellis
Visual C++ Libraries
james.mcnellis@microsoft.com
Posted by Peter Esik on 2/17/2015 at 1:36 AM
I stumbled upon the very same problem. I think i narrowed the cause down a bit more, see this connect entry: https://connect.microsoft.com/VisualStudio/feedback/details/1134693
Posted by Andrew7Webb on 12/17/2014 at 10:06 AM
I ran into a LNK2001: unresolved external symbol __vsnwprintf_s on VS2015 preview.
For me, it only occurs when compiling for RELEASE, and the same source does compile and link without errors in DEBUG.
I use multi-byte character set, and static C++ runtime libraries.
Posted by Microsoft on 11/25/2014 at 6:38 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. In order to efficiently investigate and reproduce this issue, we are requesting additional information outlined below.

Could you please give us a demo project so that we can conduct further research?

Please submit this information to us within 4 business days. We look forward to hearing from you with this information. If you require immediate assistance with this issue, please contact product support at http://support.microsoft.com/ph/1117.
Posted by Microsoft on 11/25/2014 at 2:12 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If you require immediate assistance with this issue, please contact product support at http://support.microsoft.com/ph/1117.