I'm trying to link my C++ VS 2015 executable with tbarcode library 8. This library consists of header files, a lib file, and a dll file.
I keep on getting errors LNK 2019, for example LNK2019: unresolved external symbol __imp_BCAlloc
I'm building in debug mode, I've added the lib to "Additional Depdencies" settings, its directory to "Additional Library Directories" and the path to the directory of the dll to the PATH environment variable.
Here are the results of dumpbin *which shows mangled names):
dumpbin /all TBarCode8.lib | findstr /c:"BCAlloc"
B8B2 _BCAlloc#4
B8B2 __imp__BCAlloc#4
7 _BCAlloc#4
7 __imp__BCAlloc#4
Symbol name : _BCAlloc#4
Name : BCAlloc
_BCAlloc#4
dumpbin /all TBarCode8.dll | findstr /c:"BCAlloc"
2 0 000247D9 BCAlloc
Questions: What does the suffix #4 mean in the mangled name? And how to solve this error LNK 2019?
I found the solution: the dll of tbarcode I was provided is 32 bit, and I tried building my app in 64 bit. Building my app in 32 bit solved the problem.
Related
I am trying to compile libpng with MinGW-w64 (x86_64). I have set up the libpng with CMake using MinGW Makefiles generator. When running the make, I get the following output:
Scanning dependencies of target png16
[ 2%] Building C object CMakeFiles/png16.dir/png.obj
In file included from C:/PROGRA~2/MICROS~3.0/VC/include/vcruntime.h:46:0,
from C:/PROGRA~2/MICROS~3.0/VC/include/crtdefs.h:9,
from C:/PROGRA~1/MINGW-~1/X86_64~1.2-P/mingw64/x86_64-w64-mingw32/include/stdlib.h:9,
from C:\CPP\deps\lpng1617\pngpriv.h:42,
from C:\CPP\deps\lpng1617\png.c:14:
C:/PROGRA~2/MICROS~3.0/VC/include/vadefs.h:28:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'uintptr_t'
typedef unsigned __int64 uintptr_t;
^
In file included from C:/PROGRA~2/MICROS~3.0/VC/include/crtdefs.h:9:0,
from C:/PROGRA~1/MINGW-~1/X86_64~1.2-P/mingw64/x86_64-w64-mingw32/include/stdlib.h:9,
from C:\CPP\deps\lpng1617\pngpriv.h:42,
from C:\CPP\deps\lpng1617\png.c:14:
C:/PROGRA~2/MICROS~3.0/VC/include/vcruntime.h:81:1: error: unknown type name 'pack'
_CRT_BEGIN_C_HEADER
^
... and more ...
Why is MinGW trying to include header files from Visual Studio? The stdlib.h at line 9 is including crtdefs.h which is being included from Visual Studio and not from MinGW directory. Why?
The crtdefs.h does exist in the MinGW directory (next to the stdlib.h)
My %PATH% variable does not contain any Visual Studio (nor Windows SDK) folders.
After more investigation, I found that build\CMakeFiles\png16_static.dir\includes_C.rsp contains -IC:/PROGRA~2/MICROS~3.0/VC/include
After several system restarts, reinstalling MinGW and CMake, and setting the environment variables to defaults, it seems to be working now. Not sure what exactly went wrong.
I need to link my project to the libmysql.dll dynamic library (I need to do it because I'm building my project as /MDd, reference: https://dev.mysql.com/doc/refman/5.6/en/c-api-building-clients.html)
Now the tricky part is that it is an import library (reference: https://msdn.microsoft.com/en-us/library/d14wsce5.aspx) so there is a libmysql.lib as well.
I'm using CMake for the build:
set(MYSQL_DIR "C:/Program Files/MySQL/MySQL Connector C 6.1"
CACHE PATH "The path to the MySQL C API library")
include_directories(${MYSQL_DIR}/include)
find_library(mysql NAMES libmysql PATHS ${MYSQL_DIR}/lib)
message(STATUS "mysql library: " ${mysql})
CMake finds the library libmysql.lib but when I try to compile I get the following linker error:
LINK : fatal error LNK1104: cannot open file 'mysql.lib'
mysql as you can check above is the name of the CMake variable that contains the path to libmysql.lib.
I have tried to link directly to the .dll but it does not work either, CMake does not find the .dll.
Question
How should I proceed in CMake to link to the import library? Thanks for any help.
You need to use result of find_library() call in target_link_libraries(). In your case it is target_link_libraries(main ${mysql}).
I'm performing the (terrifying) task of building LLVM 3.3 on windows and I have got to the stage where I have a load of LLVM*.lib files. I want to link them together to one huge shared DLL but am struggling (this is my first time linking stuff on windows). I've tried:
link /DLL /MACHINE:X64 /OUT:LLVM3.3.dll LLVM*.lib
but to no avail. It errors with:
LINK : warning LNK4001: no object files specified; libraries used
LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup
LLVM3.3.dll : fatal error LNK1120: 1 unresolved externals
The internet suggested adding the /DEFAULTLIB:corelib switch, so I did that but again it has problems:
> link /DLL /MACHINE:X64 /DEFAULTLIB:corelibc /OUT:LLVM3.3.dll LLVM*.lib
LINK : warning LNK4001: no object files specified; libraries used
LINK : fatal error LNK1104: cannot open file 'corelibc.lib'
How do I do this?
EDIT: I managed to fix the above problem, by implementing an empty DllMain and making an EmptyDllMain.obj from it:
#include <windows.h>
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
and then trying:
link /DLL /OUT:LLVM3.3.dll LLVM*.lib EmptyDllMain.obj
but the DLL I get out is just 8kb - it seems to have missed out the many megabytes of LLVM libraries! How do I get them included?
EDIT2: I solved the LLVM compilation on Windows problem, take a look at this document on github.
I had this once while linking one lib with a wrong platform set together (X86 to X64). Make sure all the LLVM*.lib are build and linked with the correct toolchain:
[...]\Microsoft visual Studio 10.0\VC\bin\amd64\ cl.exe and link.exe
which you get by calling
"%PROGRAMFILES(X86)%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" amd64
Also I had similar problems when mixing MT and MD CRTs, I recommend you stick to
/MD (or /MDd for debug)
when compiling the objects for any of the LLVM*.lib (and any other objects from other external libraries you link into these).
[edit]
And kick out that ugly EmptyDllMain.obj !
[/edit]
If you manually entered the _DllMainCRTStartup, be sure you spelled it (watch case) correctly. I had _DLLMainCRTStartup and took a while to catch why I still received the linker error. For Windows CE, the required link lib is corelibc.lib.
remove lib files from "ignore specific default libraries" from "Linker->Input" on project properties
I've been attempting to use libsndfile (it is the windows 64 bit version) for the first time, and have encountered a problem while trying to link it. Whenever I try to compile the program, I get this error:
error LNK2019: unresolved external symbol _sf_close referenced in function _main
This is the process I've done so far to attempt to link it to the program.
In project properties I have gone to Config. Prop.-> VC++ Directories, and added the path to the header files to the include directories tab, and the path to the .lib files to library directories tab.
In C/C++-> General-> Additional Include Directories, I have added the path to the header files.
In Linker->Input->Additional Dependencies I have added the path to the .lib file, which for me is C:\Program Files\Mega-Nerd\libsndfile\lib\libsndfile-1.lib
I've added #include "sndfile.h" to the .cpp file but for some reason it doesn't seem to have access to the functions in the dll. I don't really know a lot about linking, and what I've done is just what I've been able to piece together from scouring the internet, so I'm not really sure on what I'm doing wrong or right. Any help is greatly appreciated.
You are probably compiling a 32 bit project in Visual Studio, and trying to link it with a 64 bit library. It won't work... download the 32 bit version of the windows binary of libsndfile and use it to link to your executable. Another option is to create a 64 bit project, but I think the first option is (slightly) easier.
I have a DLL that I am trying to link with a libjpeg LIB using MSVC 2008 that is generating Unresolved External Symbol errors for the libjpeg functions. I also have a test project that links with the exact same libjpeg library file and links without error and runs fine too.
I have triple-checked my LIB path and dependent LIBS list settings and literally copy and pasted them from the EXE project to the DLL project. I still get the errors. I do have the libjpeg include headers surrounded by extern "C" so it is not a name mangling issue and the unresolved external warnings show the "missing" libjpeg functions as undecorated (just a leading underscore and the # sign parameter byte count suffix after each name).
What could make the linker with the DLL project be unable to find the functions properly when the test EXE project has no trouble at all? I'm using the pre-compiled 32-bit static multi-threaded debug library which I downloaded from ClanLib.
Thanks,
Robert
After a lot of experimentation I found the solution. It turns out the problem was due to a difference in the calling convention used by the DLL and the LIB projects (In MSVC 2008 this is set on the Project Properties, "Configuration Properties -> C/C++ -> Advanced" setting. The DLL project was set to __stdcall and the LIB was __cdecl. Recompiling LIBJPEG with __stdcall fixed the problem.