unresolved external symbol __imp__wcsstr - c++

I am getting the following linking error : libOpenSSL.lib(cryptlib.obj) : error LNK2001: unresolved external symbol __imp__wcsstr while linking he openssl library to my project. But this looks like a generic error than a openssl error.
Anybody having any idea, i am missing to include any windows library?

I resolved this error. Need to include Msvcrt.lib to resolve this error.

Related

unresolved external symbol inflateEnd (and others) while using boost Zlib

I'm in the process of converting 32bit project to x64. In most cases it just means appending 64 to library paths (and eventually building those libraries for x64). Now I assume all libraries are already ready and the code is also x64 compatible. But I keep getting errors for boost zlib library, like these:
error LNK2019: unresolved external symbol inflateEnd
error LNK2019: unresolved external symbol inflate
error LNK2019: unresolved external symbol inflateInit_
error LNK2019: unresolved external symbol deflateEnd
error LNK2019: unresolved external symbol deflate
error LNK2001: unresolved external symbol "int const boost::iostreams::zlib::default_compression"
error LNK2001: unresolved external symbol "int const boost::iostreams::zlib::deflated"
error LNK2001: unresolved external symbol "int const boost::iostreams::zlib::default_strategy"
I enabled verbose mode for linker (in MS Visual Studio you do this by adding /VERBOSE:LIB to additional linker options). Thanks to that, I can see this output line:
Searching .\..\..\libs\boost145\stage\lib64\libboost_zlib-vc100-mt-gd-1_45.lib
That would imply that the library was found in the boost145\stage\lib64. So what should I be looking for now?
One strange thing is that file that defines the first group of missing symbols (those that are not within boost) has header files within the project, zlib.h and zconf.h. Maybe this is some hint? The zlib.h defines external symbols as:
ZEXTERN int ZEXPORT inflateEnd OF((z_streamp strm));
Obvious question is: where the hell is lib file for this header file?
I had the same issue, to resolve the errors I download the source from zlib and built the x64 dlls/libs locally. There were a couple issues with solution file downloaded, fixes are described below.
Zlib 1.2.8 source code: http://zlib.net/zlib128.zip
Solution File for VS2012 is located at: zlib-1.2.8\contrib\vstudio\vc11\zlibvc.sln
Fixes:
Change:
<Command>cd ..\..\..\contrib\masmx64
bld_ml64.bat</Command>
to:
<Command>cd ..\..\contrib\masmx64
bld_ml64.bat</Command>
In zlibvc project properties -> Linker -> Advanced -> Image Has Safe Exception Handlers -> set to No (/SAFESEH:NO). Info about SAFESEH: Compiling libffi with VS2012 fails with fatal error LNK1281: Unable to generate SAFESEH image

DLL linking to static libraries

We have a project which is an executable, which loads DLL files at run time as plugins.
We're trying to make a new plug in which has many library dependencies, and some of those dependencies are the same library but different versions that other plugins link to.
Because the libraries are depended on by different plugins at different versions, I would like to statically link/build any dependencies into the new plugin - that way they can't conflict with the old plugin dependencies. As far as I know, nothing in the dependencies of the plugin need to be exported, they're just used by the plugin.
Is it possible to do this?
I've tried building all the static libs in visual studio as static libraries with the runtime set to Multithreaded DLL with the /MD flag, but when I try to build dynamiclibB.dll, I get linker errors. If I set dynamiclibB to build as a static library, it doesn't have the linker errors.
I haven't tried linking newplugin.dll to the static library version of dynamiclibB yet, but I think I have exactly the same situation, so I see no reason why it would work there where it doesn't one level down.
I don't want to build dynamiclibB as a static library anyway, as it would be good to be able to update newplugin.dll without including dynamiclibB.dll if it hasn't been changed, as in, to decouple the update process. This line of reasoning would suggest that I should have .dlls for everything, but the conflicts of versions is what worries me, I think.
I cannot build the plugins as static libraries as they need to be loaded at run time.
Absolutely everything is being built in release mode for now, to avoid that complication.
What am I missing?
An attempt at a diagram that might help understand the situation:
program.exe
|
________________
| |
oldplugin.dll newplugin.dll
| |
dynamiclibA.dll dynamiclibB.dll
|
_________________________
| | |
staticlibA.lib slibC.lib slibD.lib
Update:
Providing some more information now that I know what's happening, and know that more specific details are actually relevant.
So library A, represented by dynamiclibA and staticlibA was zlib.
The library we were compiling (dynamiclibB) for use in the newplugin was PoDoFo.
The error messages we got were:
Error 19 error LNK2001: unresolved external symbol
_deflateInit_ E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 20 error LNK2001: unresolved external symbol
_inflateEnd E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 21 error LNK2001: unresolved external symbol
_inflateEnd E:\Work\podofo_bin\src\libpng16.lib(pngread.obj) podofo_shared Error 22 error LNK2001: unresolved external symbol
_deflate E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 23 error LNK2001: unresolved external symbol
_deflate E:\Work\podofo_bin\src\libpng16.lib(pngwutil.obj) podofo_shared Error 24 error LNK2001: unresolved external symbol
_deflateEnd E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 25 error LNK2001: unresolved external symbol
_deflateEnd E:\Work\podofo_bin\src\libpng16.lib(pngwrite.obj) podofo_shared Error 26 error LNK2001: unresolved external symbol
_inflateInit_ E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 27 error LNK2001: unresolved external symbol
_inflateInit_ E:\Work\podofo_bin\src\libpng16.lib(pngrutil.obj) podofo_shared Error 28 error LNK2001: unresolved external symbol
_inflate E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 29 error LNK2001: unresolved external symbol
_inflate E:\Work\podofo_bin\src\libpng16.lib(pngrutil.obj) podofo_shared
Putting the rest in an answer.
In my question, slibc.lib was libpng. Libpng also requires zlib, but it builds it from source inside its solution. We were able to use the output of that project in the way we desired, as in, zlib.lib built with /MD flag, without linking errors.
We've also managed to work out why this problem occurred:
another stackoverflow question was very relevant: https://stackoverflow.com/a/6559315/78823
Turns out that zlib has a #define ZLIB_WINAPI which defined the call convention to be STDCALL, which I don't understand, but it caused the linker errors. The other answer suggests to remove the define, and I suppose that's what libpng did with its zlib project.
I'm guessing that the reason why the linker errors only occurred when building the .dll and disappeared when building the .lib is because (correct me if I'm wrong, I don't fully understand this), build a .lib doesn't actually do the linking to the required functions, so would have been just passing on the linker errors to the next level up; I think we would have seen the same errors (but in different objs/projects perhaps) when compiling newplugin.dll, but we didn't get far enough to check that before we tried other things.

Unresolved external symbols in C++ project

This is my situation (I am very new to C++ MFC coding and I am trying to debug an existing application project)
I use this line in my code (in a visual studio 2012 MFC project)
CoCreateInstance(CLSID_PortableDeviceValues, NULL,
CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&x));
While I run the project, i get a linker error like this
error LNK2001: unresolved external symbol _CLSID_PortableDeviceValues
This happens for all the CLSID values that I am referring to in the code. Like this
error LNK2001: unresolved external symbol
_CLSID_PortableDeviceKeyCollection
error LNK2001: unresolved external symbol _IID_IPortableDeviceEventCallback
error LNK2001: unresolved external symbol _CLSID_PortableDeviceManager
error LNK2001: unresolved external symbol _CLSID_PortableDeviceServiceFTM
I checked for the declaration of "CLSID_PortableDeviceValues" and it was found in "PortableDeviceTypes.h" and I have imported that library as well.
I do not get any compiler error, but run into the linker errors mentioned above..
Can someone please help me out here. I could not resolve this ..
You will need to add PortableDeviceGUIDs.lib to your project.
(Look up the section "Requirements" in the MSDN documentation for IPortableDeviceValues)
When the linker builds your project, it is looking for the implementation data that is behind the identifier CLSID_PortableDeviceValues. This data is in the library PortableDeviceGUIDs.lib, and the linker has to be told to use this library.
The header file you included in your source code only declares the symbol "CLSID_PortableDeviceValues", without importing its implementation.

Why will I have link errors when invoking a library (building the library is successful) in C++

I have a question related to invoking a C++ library. The compilation of the library is successful. After that, the library is invoked by a normal executable program. However, several link errors occur.I give an example to illustrate my problem.
I have download an old version of TIFF library (version 3.6.1) and then compiled it to a static library: tiff.lib. After that I wrote an executable program for reading and writing TIFF files by invoking the library. However, the following errors appear:
2>tiff.lib(tif_jpeg.obj) : error LNK2001: unresolved external symbol __TIFFmalloc
2>tiff.lib(tif_lzw.obj) : error LNK2001: unresolved external symbol __TIFFmalloc
2>tiff.lib(tif_dirinfo.obj) : error LNK2001: unresolved external symbol __TIFFmalloc
2>tiff.lib(tif_luv.obj) : error LNK2001: unresolved external symbol __TIFFmalloc
2>tiff.lib(tif_pixarlog.obj) : error LNK2001: unresolved external symbol __TIFFmalloc
2>tiff.lib(tif_zip.obj) : error LNK2001: unresolved external symbol __TIFFmalloc
2>tiff.lib(tif_dirwrite.obj) : error LNK2001: unresolved external symbol __TIFFmalloc
2>tiff.lib(tif_write.obj) : error LNK2001: unresolved external symbol __TIFFmalloc
2>tiff.lib(tif_dirread.obj) : error LNK2001: unresolved external symbol __TIFFmalloc
I cannot understand why I will receive link errors as tiff.lib has been built successfully and it has also been linked successfully by my executable program. If something wrong with tiff.lib, I expect the link errors should appear during the compilation and link procedure when building the lib. Any ideas will be appreciated!
EDIT: I add some details in order to find the solution. tiff.lib is built as a static library, and when I use dumpbin.exe /exports tiff.lib to display all definitions exported in the library, the following message is given:
Dump of file tiff.lib
File Type: LIBRARY
Summary
3B8 .bss
9405 .data
D5640 .debug$S
C38 .debug$T
C4E .drectve
19E79 .rdata
84 .rtc$IMZ
84 .rtc$TMZ
3363E .text
It seems that no symbols are exported.
I think tiff.lib is C library and you are linking in c++. So I guess you will need to use extern "C" to include its header .h file.
extern "C"
{
#include<tiff.h>
}
Something like that above is just example. Also make sure you are setting correct calling convention in project property page of your c++ project
C/C++ ----------> Advanced ---------->Call Convention--->_cdecl(/Gd) //Set only if required
C/C++----------->Advanced------------>Compile As----->C++ Code(/TP)
Based on the discussions, I have come to realize that my program's error lies in the fact that some functions have not been defined correctly. It may happen that in some libraries the function may be declared in the head file with the keyword "extern". However, the implementation of the function is defined in another file, which could be excluded when building the library. Function calling conversion, as explained by #praks411, is another scenario, which you should consider when you meet with the same problem.

'LIBCMT' conflicts with use of other libs + unresolved external symbols

I have a program using OpenGL 3.2(+libs) and FreeType2. Then an other program with Boost and OpenSSL. The OpenGL side was to make sure text could be rendered and the boost/openssl program is to do a secure login/game server.
Both programs work fine by them selfs.
However adding Boost and OpenSSL to the game(GL + freetype) project caused it to fail to link.
I have linked the following libs as well as including there includes folder.
glimg.lib
glutil.lib
glfw.lib
opengl32.lib
freetype.lib
glew32.lib
user32.lib
libeay32.lib
ssleay32.lib
The linker error is.
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol __imp__DeregisterEventSource#4
1>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol __imp__ReportEventA#36
1>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol __imp__RegisterEventSourceA#8
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__DeleteDC#4
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__DeleteObject#4
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__GetBitmapBits#12
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__BitBlt#36
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__GetObjectA#12
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__SelectObject#8
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__CreateCompatibleBitmap#12
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__GetDeviceCaps#8
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__CreateCompatibleDC#4
1>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol __imp__CreateDCA#16
1>.\BasicTexture.exe : fatal error LNK1120: 13 unresolved externals
Runtime Library is set to Multi-threaded DLL (/MD)
I have no idea what to do I would really appreciate any help.
You are trying to compile with /MD, which is probably the right choice, but some code (probably one of the libraries) was built with /MT, and you can't have it both ways in the same program. You need to figure out which library was built with /MT and rebuild it with /MD.
Unresolved external error messages are produced when the compiler generates code referencing externally defined objects or functions and the linker fails to find those. To generate code invoking a function call the compiler only needs a declaration:
extern "C" BOOL DeregisterEventSource ( HANDLE hEventLog );
This is enough information to produce a call instruction (except for the target address). The extern keyword informs the compiler that the implementation is defined elsewhere. Consequently it cannot know the target address which has to be filled in later. When the compiler is done it is the linker's job to connect the pieces together. It uses the information gathered from the import libraries to look up the required offsets.
Windows API calls are easily spotted in the error log. They have an __imp__ prefix and sometimes an A or W postfix followed by #<n> where <n> indicates the number of bytes required for the arguments. In the case of a Windows API call you can then look up the function in the MSDN (like DeregisterEventSource). Towards the bottom are the Requirements where you can find the import library name.
The conflict warning indicates that not all of the modules use the same runtime library. Even though this is just a warning it is a serious issue and should be resolved. You get this warning if you mix /MD and /MT compiler switches, but also, if you mix release and debug runtime libraries (like /MD and /MDd). To diagnose this message you can use the /VERBOSE:LIB linker switch to determine which libraries the linker is searching. Additional information on this warning can be found at this MSDN link.