i have here a strange behaviour with VS2012.
I have a C++ dll project, with an export defnition file. In Debug built everything is fine, a dll and a lib file is generated.
In Release built only a dll file is generated.
Best
Tom
Make sure that the .def file is specified in the project's Propert Pages in Configuration Properties | Linker | Input | Module Definition File in both the Debug and Release configurations.
Related
TL;DR
How do I configure CMake and Emscripten to build my static library to produce a WASM and JS bootstrap file?
I have a static library being built with CMake that I want to build as a WASM library (and JS bootstrap) using Emscripten. Simply using the Emscripten CMake toolchain and adding the appropriate compiler/linker flags result in only a .a file being built - even if -o <project name>.js is added to the compiler and/or linker flags.
The reason is that because I've told CMake I want a static library, it uses CMAKE_AR to build. CMAKE_AR (if undefined) is defined as emar in the Emscripten toolchain file, and emar cannot produce .wasm and .js output.
I have tried creating a new executable target that has a dependency on the library, and otherwise just sets up the compiler/linker settings. However this causes a CMake error, because I've defined an executable target that has no source files (they're associated with the library target). If I add a stub main file, I get an Emscripten warning:
system_libs:WARNING: main() is in the input files, but "_main" is not in EXPORTED_FUNCTIONS, which means it may be eliminated as dead code. Export it if you want main() to run.
I could get round by adding an empty file to exe source file list (probably, I haven't tried), but this feels very much like a hack.
You are correct in that you need to create an executable target in order to produce a .wasm file.
If cmake insists on you creating a dummy source file because it doesn't understand that all the code for your program can come from libraries then I guess you that is your best option.
See CMake: Is it possible to build an executable from only static libraries and no source? for how to work around this limitation of cmake.
I made an application with Qt5(mingw). To run this application out of qtcreator, I have to put some dlls like Qt5Widgets.dll, Qt5Core.dll, ... beside the executable file. I tried to add these libraries to project, but "Add Library" option doesn't accept dll! I can only add static library(*.lib).
I just want to add required dlls to my project and make a *.exe file in output, without any dependency and no any dll around the executable file.
You want to build your application with static linkage. For static linkage you need to compile your Qt with -static option.
How to build static Qt:
For linux: http://doc.qt.io/qt-5/linux-deployment.html
For Windows: I used this guide https://wiki.qt.io/Building_a_static_Qt_for_Windows_using_MinGW
Note: even with static linkage I provide msvcr110.dll and msvcr120.dll with my app, so I have .exe + 2 dlls. But maybe I do some things wrong, but at least I have 3 files instead of tons of it.
IDE: VS2005
Say I am using Poco library and the executable needs below dlls. I have to put them in same directory where the executable is.
msjava.dll
msvcp80.dll
msvcr80.dll
PocoFoundation.dll
PocoNet.dll
Is there any way that can build a dll-free executable? Thanks.
They don't have to be in the same directory. They can be in another directory if your PATH variables includes the directory they are in.
It looks like the Poco libraries can be downloaded as source, so you should be able to build them as static libraries and make a stand alone executable.
Update
For the msvc DLL's, you can build against static libraries. Bring up the properties of your project, go to C/C++, Code Generation and modify "Runtime Library". Make sure to choose a library other then "Multi-threaded DLL" or "Multi-threaded Debug DLL." You will also want to make sure you do that for the Poco libraries as well.
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.
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."