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
Related
I'm using Atmel Studio 6.1.2 SP2. I'm setting up CppUTest for our embedded system project.
I created a static CPP library for the CppUTest Framework which copiled successfuly after a small change. Now I'm including this library to a test project. A C++ application project.
The issue I'm facing now is that even though the intellisense is auto completing my include, that means that it sees where the library is, I get "No chuch file or directory" error when compiling.
In GccApplication1.cpp I have this:
#include <avr32/io.h>
#include <CommandLineTestRunner.h>
int main(int ac, const char** av)
{
/* These checks are here to make sure assertions outside test runs don't crash */
CHECK(true);
LONGS_EQUAL(1, 1);
return CommandLineTestRunner::RunAllTests(ac, av);
}
And the error is that it can't find the CommandLineTestRunner.h. I tried with "" and <> but it doesn't see it.
Any ideas?
For more information. I'm following the steps from Atmel, here is the tutorial:
Adding the library only tells the linker that the file is available to be linked with the rest of your object code. What appears to be missing is telling the compiler where it can find the header files for the library. If you add the library path to your include list you should be good to go.
The "No such file or directory" error is a preprocessor error. It is telling you that the include file cannot be found in the include file path. Your IDE will have a way to specify the include path.
If you are using make, then you will want to use the -I option.
If you are using CppUTest's MakeFileWorker.mk, you will want to add define an environment variable, CPPUTEST_HOME, that specifies the directory where you installed CppUTest.
I hope that helps.
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.
Question: why would an application not find the DLL “boost_thread-vc100-mt-1_46_1.dll” when the DLL is in fact properly installed, and other applications use the DLL successfully?
Problem: when starting an instance of my application, the following error message appears:
“The program can’t start because boost_thread-vc100-mt-1_46_1.dll is missing from your computer. Try reinstalling the program to fix this problem.”
Several reasons why this message confuses me:
The dll is present in C:\Program Files(x86)\boost\boost_1_46_1\lib
Another project with similar settings runs properly and does create
boost::thread objects successfully
When I remove the code that creates boost::thread objects from my application, the error
message does not appear.
Additional details:
I am developing a C++/CLI application using MS VS 2010 with CLR enabled.
I am using the Boost Thread library (version 1.46.1).
Following the advice on posts about using Boost Thread and C++/CLI, I added the following code to one of my header files:
#if defined(_MANAGED)
#define BOOST_USE_WINDOWS_H
#endif
#define BOOST_THREAD_USE_DLL
#include "boost/thread.hpp"
namespace boost {
struct thread::dummy {};
}
#pragma warning(push)
#pragma warning(disable:4793)
#include "boost/thread/mutex.hpp"
#pragma warning(pop)
#include "boost/thread/locks.hpp"
I appreciate any advice you may have. Thank you.
Being in C:\Program Files(x86)\boost\boost_1_46_1\lib doesn't help much.
It needs to be in the DLL search path.
Other applications using boost probably have a local copy of the DLL alongside the main executable.
You need to add the location of the boost libs to the linker search path.
Right click on the C++ project that is showing the linker error, select Properties. Go to Linker -> General then in the right hand panel you see Additional Library Directories. Put in the path to the folder holding boost_thread-vc100-mt-1_46_1.dll - typically this folder will hold all of your boost libs and will be something like D:\Program Files\boost\boost_1_49_0\stage\lib.
Now the linker will search that folder when looking for libs, and everything should work.
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.