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.
Related
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 am using Visual Studio 2008 trying to create a .dll. The dll uses an external library (.lib). Compiling and linking works fine (I included the paths to header/lib in the options). When my .dll is used by a program (as a plugin) it says "externalLibrary.dll missing" but there is no externalLibrary.dll, just a externalLibrary.lib.
Are there different options of linking (so the externalLibrary is already in my .dll)? Or can i simply create a .dll from the .lib? Or any other solutions to this problem?
Edit (to be more concrete):
In project properties i added
the header path # C/C++ - General - Additional Include Directories
the library path # Linker - General - Additional Library Directories
the library name # Linker - Input - Additional Dependencies (although
this doesn't change anything)
The .lib file you are using is an import library which basically means that it contains only stubs for functions/classes/... but not the actual implmentation. That implementation is in the dll. An import library is only useful for the linker as it uses it to resolve symbols. But at runtime, the actual compiled code is needed so your application/dll looks for the dll. But even if your dll is used as a plugin, it's no problem for it to depend on other dlls. So if you have the other dll I suggest you go that way. (what is 'externalLibrary' btw?, it's not normal a vendor supplies you only with an import library and not the dll)
If you really do not want to use the external dll, you'll have to find the static library for the code of 'externalLibrary'. Unlike the import library, a static library does contain all symbols complete with actual implementation etc. So after linking with a static library, your application/dll contains the code itself and does not need to resolve it at runtime.
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'm just trying to set up a simple project that shall be able to compile on every platform, that is supported by CMake. I started my project on a Win7-system and wrote a little main.cpp that includes SDL.h and GL/glew.h. The style of the main-function is simple c++:
int main(int, char**) {}
In my CMakeLists.txt I call find_package(SDL) and find_package(GLEW). The CMake-part works well, so I just opened the vs10-solution-file and tried to compile when I get the LNK2019:
error LNK2019: unresolved external symbol main referenced in function __tmainCRTStartup
This would mean that I chose the wrong subsystem, doesn't it? But if I simply toggle the subsystem from CONSOLE to WINDOWS and back the problem still exists. Has CMake set a hidden option for that? How can I compile my simple program in vs10?
I had this problem tonight. I'm using CMake to create an MSVC project to build my GLFW app. Of course, the age-old trick for getting rid of the console window if you're using MSVC by itself is to go in to the properties and set "Subsystem" to "Windows" and "Entry Point" to mainCRTStartup, which corresponds to adding the /SUBSYSTEM:WINDOWS /ENTRY:"mainCRTStartup" flags to link.exe, but CMake doesn't provide an easy way to do that.
If you just do a straight-up add_executable() command, you'll get /SUBSYSTEM:CONSOLE /ENTRY:"mainCRTStartup" being passed to the linker.
If you do an add_executable(exename WIN32 ...), you'll get /SUBSYSTEM:WINDOWS.
Gaah! Either option gets us halfway there!
I poked through the .cmake files that CMake ships with (fwiw, I'm using CMake 2.8.10 and Visual Studio 2012 Express), and discovered that the variable that seems to control the /SUBSYSTEM and /ENTRY flags is called CMAKE_CREATE_WIN32_EXE. So to set both parts, we just have to change that variable. Here's what I ended up with, which did the trick:
if(MSVC)
set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWS /ENTRY:\"mainCRTStartup\"")
endif(MSVC)
Hope that helps someone else.
I got a .h file, two .lib files, a .dll file and a tiny test project from a hardware vendor to talk to their hardware.
Compiling and running their test project works just fine. Noteworthy: they don't use the .dll. I can throw the dll-directory and all of it's content away, everything works just fine.
To start things off I simply copied the communication parts of their code (connect, disconnect and send a command) into my project. This is actually all that you can do. I have included the .h file and pointed to the directory containing the .lib files. Just like in the tiny test project. It all compiles, but when I try to run the project complains that it is missing the .dll file.
Can anybody explain what is happening? How are libs and dlls supposed to work?
All of this is on windows, VS2005. I compared the .vcproj files and could not find any significant differences.
The test project is statically linked - the lib is included in the exe.
Your project is dynamically linked - the dll is referenced and therefore needed at runtime.
See this Stack Overflow question for more information.
Basically the answer depends on whether you are going to use static or dynamic linking for your executable.
With static linking, you need the .h and .lib files but not the .dll files to compile and link. Your executable will be larger but you won't need any of the .h/.lib/.dll files during runtime.
With dynamic linking, you just need the .h files to compile and link. Your executable will be smaller but you will need one or both of the .dll files during runtime.
For a more detailed treatment of this from the Visual Studio perspective, check out http://msdn.microsoft.com/en-us/library/1ez7dh12.aspx -
"Dynamic linking differs from static linking in that it allows an executable module (either a .dll or .exe file) to include only the information needed at run time to locate the executable code for a DLL function. In static linking, the linker gets all of the referenced functions from the static link library and places it with your code into your executable."