There is a short response from Microsoft regarding this issue:
https://connect.microsoft.com/VisualStudio/feedback/details/470376/odbc-application-linking-with-odbccp32-lib-gets-link-errors-in-vs2010-beta-1?wa=wsignin1.0#tabs
Basically, their response doesn't seem to address the problem.
Our application needs to statically link to the C libraries, but there is a linker error when attempting to do so. Microsoft's answer seems to be "dynamically link instead", but that's not an option. Their alternative is to "Use the version of odbccp32.lib that came with Vista SDK." However, I am unaware as to how to force VisualStudio 2010 to use a different version of the ODBC library?
I just spent the last hour trying every conceivable search through the .vcxproj and .sln files for any references to odbccp32.lib. None. I similarly looked for ODBC. None. Looking at all of the compiler & linker options for the project(s) in question: nothing refers to ODBC whatsoever. The only connection between our application and ODBC I can see is the #include <sql.h> and <sqlext.h>. However, even those files do not refer to odbccp32.lib (or any other .lib or linker option).
The only references to odbccp32.lib I can find at all are in .obj files. So it appears that VS2010 automagically knows which ODBC libraries to link against based on what functions are referenced in our software (SQLConnect(), for example).
So how might I:
1) "obtain Vista SDK version of odbccp32.lib"?
2) cause VS2010 to link against that version?
-OR-
Is there a better way to solve this?! Right now I am unable to proceed with a conversion of our software from VS2008 -> 2010 unless I can find a way to force this goofy software to compile.
NOTE: Apparently I could force the system to compile using 2008's tooling, which may "cure" this. But that means changing all of our projects up & down the chain to do this, which is rather backwards and contrary to the whole point of moving to 2010, no?
For the curious, the exact linker error:
odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol __imp___vsnprintf referenced in function _StringVPrintfWorkerA#20
Reading through your link, it seems that Microsoft has verified that there is a problem, and they intend to fix it in the next version of the SDK. Doesn't help much, does it?
It's quite normal for the linker to daisy-chain through the objects, linking one object only to discover that it has dependencies on other objects. If you want to preemptively link to a specific library, add it to the "Additional Dependencies" in the Linker Input tab of the project properties.
If you aren't able to get the linker to prefer a specific version of a library, just seek out and replace the version of the library in the installation.
I think this is a link to the Vista SDK, but I can't verify it: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ff6467e6-5bba-4bf5-b562-9199be864d29&displaylang=en
I see it. Ouch, my condolences. Their advice is about as best as it is going to get if you don't want to compile with /MD. I think I know the source of the problem, this isn't that easy to fix for them either. It's going to require them getting the VS2010 CRT header file fixed first, then recompile and issue an SDK update. That takes some major doing.
It is getting linked because it is listed in the "Core Windows Libraries" property sheet. View + Property Manager to see it. Not linking it is not an option, you are probably actually using it when you #include <sql.h>
The Vista version indeed doesn't have the same problem, it was probably built with an earlier version of VS. Project + Properties, Linker, Input, Additional Dependencies = "c:\program files\microsoft sdks\windows\v6.0a\lib\odbccp32.lib". This injects the vista version before the 7.0 version. You may have to live with this for a while, be sure to keep VS2008 installed on your build machines.
I just encountered the undefined __imp___vsnprintf symbol while converting an ODBC application to Visual Studio 2015. Figuring that there must be a workaround, I dumped all the symbols exported by the various libraries in the Visual Studio 2015 LIB directories with DUMPBIN and found that this library with a most obvious name, legacy_stdio_definitions.lib, defines these symbols.
Adding this to the LINK command line resolved the missing external referenced by odbccp32.lib.
Once one knows what to search for, some info is available here.
Don't know all the details, so shooting in the dark. When I had a situation when certain functions were available with one compiler and not the other, I created a simple DLL with the functions exported with C interface, using compiler version that supported those functions, and used that DLL with another compiler.
the solution is to link with just odbccp32.lib from v6.0 sdk all else from the default sdk.
1. download v6.0 sdk from: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ff6467e6-5bba-4bf5-b562-9199be864d29&displaylang=en
(do not install documentation and samples/examples, the result is 75MB downlaod):
2. create a folder, some folder.
for example: lib_odbc_fromsdkv6.0 in your project's folder
3. copy the file odbccp32.lib from:
C:\Program Files\Microsoft SDKs\Windows\v6.0\Lib
to folder created above (only one file).
4. in each project's properties add that (lib_odbc_fromsdkv6.0) directory to Library directories:
VC++ Directories -> Library directories
the depended projects in myodbc are myodbc5S and myodbc-installer.
(from Mordachai)
Related
I have problems building my code that is using static lib detours. I am trying to do an old basic CTF. For that I want to get into detours.
Whenever I try to build my .dll file I get an issue
LNK2019 unresolved external symbol _DetourTransactionBegin#0 referenced in function _DllMain#12
Now, I have built the detours library using 3 different version of the visual studio dev console.
I have tried firing 'vcvars32.bat' and then using nmake to build the library which was able to build it, but I get the above error during linking my .dll. I have also tried building it with 'vcvarsamd64_x86.bat' and then using nmake to build it which also was able to build the library, but I still get the same error as above during linking.
I have tried the usual stuff: the include folder for detours.h is added to C++/General/Additional Include Directories.
Under Linker/Additional Library Directories I added them as follows: "C:\temp\det_retry\lib.X64";"C:\temp\det_retry\lib.X86";%(AdditionalLibraryDirectories).
And also under Linker/Input/Additional Dependencies I have the following: detours.lib;%(AdditionalDependencies)
What am I missing here? This is a blocker for me for a couple of days and I am reiterating the same steps trying to figure out what's missing but I cannot see. I'd really appreciate the input.
I am sure I am using the newest version because I have downloaded (cloned) detours from the ms github page.
It appears your "Additional Library Directories" are setup incorrectly or contain invalid entries rather. They look like actual library file entries (i.e. pointing to some specific files) versus being only directories (e.g. "my/lib/path/for/my_project/"). Visual Studio's naming conventions are somewhat cryptic but they should be directory entries only. There should be an entry to whatever directory contains the detours.lib file (e.g. "MyProject/Libs/MSDetour" ... where MSDetour is a folder with the "detours.lib" in it) and then Visual Studio should find the library and link everything correctly.
As a side note, if you are using the Visual Studio developer console for building your project/solution you might want to look into CMake ... it is, in my opinion, significantly easier to work with (less "settings" digging) and maintain in the long-run.
I've recently decided to try out PostgreSQL as the database platform for some C++ development I'm working on. I decided to use libpqxx as the connection library for my project, and quickly found out this would be an uphill battle to do from VS 2015 on a Windows 10 machine.
After much teeth-gnashing and nail-biting, I have gotten libpqxx to compile on Windows 10.
This leaves me with the following directory structure
Per libpqxx's documentation, I also placed a copy of libpq.dll in my project's executable directory. Please note: I have done this for both debug and release builds, tried to build both, and ended up with the same result.
All the tutorials I've seen seem to indicate that the library can be used after linking it and simply #including pqxx/pqxx, so I set up a small project to do just that. I receive the error:
fatal error C1083: Cannot open include file: 'pqxx/pqxx': No such file or directory
When attempting to build the project. I have also tried this will both debug and release builds, to no avail.
Here is a screenshot of my linker settings.
Does anyone have any suggestions for how I might be able to link and use this library from Visual Studio 2015?
As Sami Kuhmonen pointed out, this was not actually a linker error, but a compiler error. I needed to include an actual header, which Visual Studio needed to be able to find. After adding the correct folder (C:\libpqxx\include in my case) to Visual Studio's "additional include directories" setting under C\C++ -> General per drescherjm's suggestion, the program compiles just fine.
For future reference:
I did also run into unresolved external linker errors after solving the initial issue. This is because you need to make sure to also link to ws2_32.lib and libpq.lib. You also need to copy some other DLL files that libpq also relies on into your libpqxx lib folder. On my system, I believe these were ssleay32.dll, libeay32.dll, and libintl-8.dll. These files reside under the root of the PostgreSQL install. The DLL step is mentioned under libpqxx's INSTALL.txt file, however I believe it stated that the DLLs resided one folder under where I actually found them.
I have also faced same issue. Then I realized that I was building ,my application as a 32bit. I changed the target to x64 and it compiled successfully
I'm having a lot of trouble linking my project with FreeImage library with VSE 2013
I've followed this answer for VS2010 to no avail: Linking FreeImage as a static library in VS2010?
I am getting LNK2019 errors when calling FreeImage functions.
I've linked the library just as I would any library. Below are the following steps I made:
Download FreeImage Source.
Open the 2008 Solution (converted to 2013) and changed Code Generation to /MDd for all projects
Attempted to build project but for some reason min/max functions were not defined So I included algorithm.h to those files and that stopped those errors.
Attempted to build project and I get an error: "Could not open "afxres.h". So I swapped afxres.h with windows.h as suggested in another topic.
Built the project -> success
Copied Fresh FreeImaged.lib to to my project
Added directory to "Additional Library Directories"
Added FreeImaged.lib to Additional Dependencies under linker
Copied FreeImaged.dll to my debug folder where the .exe is being built
Added FreeImage.h to the project
Added #define FREEIMAGE_LIB before including the header
Attempted to build my project -> LNK2019s everywhere.
If anyone has been able to build FreeImage on VS2013 and could share how they did it I would greatly appreciate it, or if anyone has any suggestions.
The reason for your troubles is that with Visual Studio 2013 some breaking changes (as outlined by Microsoft) were introduced in related to C++11 conformity.
One includes that in order to use std::min()/std::max(), you now have to include the header . This also concerns FreeImage. Unfortunately, up until version 3.6.1 (the most recent as of today) this hasn't been fixed yet.
This blog post explains what you need to do to get it to compile. The most relevant part is:
Specifically, you will need to add
include <algorithm>
to the following files:
Source/OpenEXR/IlmImf/ImfOutputFile.cpp
Source/OpenEXR/IlmImf/ImfScanLineInputFile.cpp
Source/OpenEXR/IlmImf/ImfTiledMisc.cpp
Source/OpenEXR/IlmImf/ImfTiledOutputFile.cpp
Source/OpenEXR/Imath/ImathMatrixAlgo.cpp
I was able to get this to work by going into the Configuration Manager unchecking FreeImage and checking FreeImageLib under build. Also disabling whole program optimization seems to make the binary size more normal and, gets rid of warnings when linking.
I know this question is over a year old. Just providing an answer to anyone google searching this problem like me.
version: FreeImage3170Win32Win64.zip
os.env.: win7 64bit visualstudio ULTIMATE 2013
operation:
1_ just unpacking the zip somewhere
e.g. (D:/library/FreeImage3170Win32Win64/FreeImage)
2_ in C/C++->General->Additional Including Directerories
add (D:/library/FreeImage3170Win32Win64/FreeImage/Dist/x32)
3_ in Linker->General->Additional Library Directerories
add (D:/library/FreeImage3170Win32Win64/FreeImage/Dist/x32)
4_ in Linker->Input->Additional Dependency
add (FreeImage.lib)
PS0: i just add a new entry to Include Directories and Library
Directories and FreeImage.lib to Linker->input in Visual Studio without rebuild the FreeImage library
:)
PS1: error LNK2019 occured when i added the FreeImage/Dist/x64 option
;( ( got no idea about this)
maybe this helps :)
trying to compile some code i downloaded, i get link error LNK1104: cannot open file 'LIBCD.lib'. i cant find this file anywhere on my computer. what is it, and can i download it from somewhere? is there another way to get the code to work?
In my case, I only wrote "LIBCD.lib" in Configuration Properties -> Linker -> Input -> Ignore Specific Library
The first hit on Google for libcd says:
This file is the static library for the debug single threaded version
of the C runtime. Visual Studio 2005 no longer supports this version
of the C runtime: instead you need to use the multi-threaded version
(libcmtd.lib) or the dynamically linked (DLL) version (msvcrtd.lib).
To fix this problem you will need to change the makefile that comes
with GLUI to get it to use a different version of the library.
and some other things that might help you.
You can fix this from the project settings. You need to add the /NODEFAULTLIB to the linker settings:
core.2f.nodefaultlib.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/core.2f.nodefaultlib.asp
This option will make the linker ignore all the /DEFAULTLIB directives - this will remove the dependency on libcd.lib. Unfortunately it will remove all the other dependencies as well so you will need to explicitly add the libraries you do need (like glut32.lib etc.) as inputs to the linker.
We have a large project using VS2008 and boost 1_42. I'm trying to upgrade to VS2010 and boost 1_44. I installed VS2010 and boost 1_44 and converted the project. Now I am trying to build, and everything compiles, but fails when linking:
LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-1_42.lib'
I have changed the include and lib directories to point to the new boost 1_44 files and I have renamed the old boost 1_42 directory.
Why is the linker still looking for a vc90-1_42 file, when it is only using 1_44 headers? Is there a way that I can determine WHY the linker wants this file? The linker obviously thinks it needs the file, but why?
I have cleaned the project and I am re-building to ensure any old build files are erased.
I've run into exactly this problem a couple of times too. It's usually been some old temporary files but like in your case cleaning didn't always do the trick straight away. Does your project include any static libs that might have been built with 1.42?
Something you can try which may or may not be helpful in tracking down your issue:
Rename the old boost directory back to it's original name
Clean the solution
Under C/C++->Command Line->Additional Options add "/showIncludes"
Under Linker->Command Line->Additional Options add "/verbose:lib"
Rebuild all
Then when you build you'll be able to see at which point 1.42 headers are included, etc. in the output window. Somehow doing this helped me in tracking down where the problem was.
Along with changing the lib directory, you need to change the name of the boost library. That's in the Linker | Input section of the project settings.
Your added comment makes it clear that the dependency on the Boost 1.42 library was being created indirectly by another library that hadn't been rebuilt.
For this you basically have two choices: either add that library as a project to your main solution, and make sure it has enough dependency information that it'll be re-built when you upgrade Boost, or use the /Zl compiler switch when you build your library. This tells the compiler you're building a library so you do not want to embed library dependencies like this.
Boost uses
#pragma comment(lib)
command to inform the linker of libraries it needs to link with. It is not an error. If Boost says you need it, it's likely you do.
On How can I find out why the linker wants this file?
There are programs which will go through your app and dlls/libs and report the content of manifests and what the binaries report they depend on. You could then scan the report for the unexpected libraries being included. We used this mainly to find libs including the previous version of the VC runtime.
Have not used the one we had in about 5 years though, now if only I could remember the name of the app!
DependancyWalker (depends.exe) will allow you to see dependancies of dll/exe but not static libs.
You could open each binary as a 'file' in MSVS and look at the manifest content by hand, but I imaging this would be a bit painful. I've not tried this with a static lib.