Jump to content

VS 2015 RC Emitting LNK2001 Errors For C Library Function Names


NoelC

Recommended Posts

trans.gif?cver=0%0D%0AHi,
 

I have a C++ solution that builds properly in VS 2013.  I've installed VS 2015 RC to figure out what may need to change in order to be able to use the new IDE when it releases.

 

Our code compiles cleanly, but we link to several 3rd party libraries that we have gotten from external sources, and the linker is putting out error messages that imply we're either missing some library that was split off from the standard library, or that maybe the 3rd party libraries have to be built with VS 2015 in order for us to link successfully.

 

The specific errors we're seeing are of the form:

 

ThrdPrtyLib.lib(error.obj) : error LNK2001: unresolved external symbol __iob_func
ThrdPrtyLib.lib(parserInternals.obj) : error LNK2001: unresolved external symbol __iob_func
ThrdPrtyLib.lib(error.obj) : error LNK2001: unresolved external symbol vfprintf
ThrdPrtyLib.lib(error.obj) : error LNK2001: unresolved external symbol vsnprintf
ThrdPrtyLib.lib(xmlstring.obj) : error LNK2001: unresolved external symbol vsnprintf
ThrdPrtyLib.lib(xmlreader.obj) : error LNK2001: unresolved external symbol vsnprintf
LIBCMT.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol vsnprintf
ThrdPrtyLib.lib(cryptlib.obj) : error LNK2001: unresolved external symbol _vsnwprintf
ThrdPrtyLib.lib(cryptlib.obj) : error LNK2001: unresolved external symbol _vsnprintf
LIBCMT.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol _vsnprintf

 

I've done a fair bit of searching on the net for this issue and have gotten a feeling that this isn't a new problem just with 2015 RC but with 2015 in general, and have seen some implication that the latter note I mentioned above (a need to rebuild all the libraries also with VS2015) may be pertinent.

 

Have you any thoughts or workarounds?

 

Thanks in advance.

 

-Noel

 

Link to comment
Share on other sites


That's the simple answer - thanks, Andre.  Chances are we won't get updated libraries until after VS2015 is released, though.  I guess it's unreasonable to hope for full compatibility at the library level (and to be fair, there are only a few errors).  But at least we already have the benefit of the updated compiler and the additional warnings it emits.  It's pickier now about creating local variables with the same names as globals or statics, which I found a couple of instances of.  And there are some changes with regard to using floating point function overloads (e.g., pow and sqrt are now double-only, you have to use powf and sqrtf).  I didn't see anything new turn up from running the code analyzer though.

 

-Noel

Link to comment
Share on other sites

Just asking :whistle:, but what is the need to "upgrade" the building environment to VS2015? :unsure:

 

Is it "better" in any way (when compared to any among VS2008, 2010, 2011, 2012 or 2013)?

Does it produce "better" (faster, leaner, etc.) .exe's?

Does a .exe compiled under VS2015 do the whatever it is supposed to do "better"?

 

As an example would a program called "compass" compiled with VS2015 draw rounder circles or more circles per millisecond?

Or would it have exactly the same functionalities and the difference would be only that it will come packed in a larger case? :w00t::ph34r:

 

jaclaz

Link to comment
Share on other sites

Improvements to the compiler may yield more efficient executables as you mentioned.  Some of us write software that taxes even the most powerful computers.

 

And they are keeping pace with evolving language standards. 

 

Another reason is to have the latest Windows SDK, so as to have access to API changes (of which, admittedly, there have been very few).  We wouldn't want to miss out on having access to that all important new function IsWindows10OrGreater().

 

Lastly, they DO make improvements to the implementation of the IDE itself, some of which actually make it easier to develop more complex software.

 

By the way, you should know that Visual Studio 2015 Community Edition is free.  And I don't even see any places for ads.

 

-Noel

 

 

 

And oh by the way, yes, it's all so we can draw the most awesome compasses.

 

JaclazCompass.png

Edited by NoelC
Link to comment
Share on other sites

With all due respect, "may yield" sounds to me more like wishful thinking than actually tested and verified facts.  :(

 

Unless I miss something obvious (very likely :unsure:) the "all important" function:

https://msdn.microsoft.com/en-us/library/windows/desktop/dn905474(v=vs.85).aspx

is basically only useful to limit the use of the complied executable on a "lower platform", i.e. I presume it might be used by people writing programs expressly targeted to Windows 10 or later, the good ol' GetVersion/GetversionEx still seemingly work fine for all practical purposes, and even if you jump to the Version Helper API, I still have to understand the exact reason why the (to me much more logical) "generic" IsWindowsVersionOrGreater function: 

https://msdn.microsoft.com/en-us/library/windows/desktop/dn424964(v=vs.85).aspx

is advised as "do not use":

Important You should only use this function if the other provided Version Helper functions do not fit within your scenarios.

 

 

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Well, as I mentioned in the original post of this thread, I have not actually achieved a successful link with it yet.

 

My comments were based on prior versions, which - yes - did improve efficiency of the running code, incrementally.

 

My comments about IsWindows10OrGreater() were a bit facetious, though regarding GetVersionInfoEx()...  It lies to you (as part of providing an automatic compatibility environment) unless you manifest your software to explicitly state that you know Windows 10.  It's not really a bad overall philosophy, but when the OS starts claiming to know more than you do about what you want when you ask what version it is, it's just more of the same of what Microsoft is becoming.

 

And yes, my code already uses IsWindowsVersionOrGreater() in a loop to determine what the REAL OS version number is for reporting, even if it's not yet manifested for the very latest and greatest.

 

-Noel

Edited by NoelC
Link to comment
Share on other sites

My comments were based on prior versions, which - yes - did improve efficiency of the running code, incrementally.

Interesting :), this is where our experience diverges, I have more often than not seen "later builds" become an increasing amount of bloat or of (unneeded) dependencies or both, JFYI, this recent experience seemed to lead to an awful amount of work needed in newer VS editions to make things simpler:

http://reboot.pro/topic/19942-vmdk-proxy-for-imdisk/

http://reboot.pro/topic/20467-use-libyal-libraries-with-devio-and-imdisk/

but of course the scope here is/was to get at the end of the day something as portable as possible and with as few dependencies as possible because the main use will be in a PE or however in compact, reduced environments.

 

jaclaz

Link to comment
Share on other sites

Well, the work I do that I've found specifically to be improved as the versions march on is code for high performance graphics operations.  We saw an improvement in speed in some critical areas when we moved to VS 2013.  Things like __vectorcall have helped us a lot. 

 

I've found the upgrades of Visual Studio since VS 2005 to be fairly painless, TBH.  Even though Microsoft attempts to upgrade the projects automatically, one DOES have to review ALL the settings since there are always new ones.

 

But, as with many things, the devil can be in the details.  Our focus is not your focus.

 

-Noel

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...