I've read multiple posts with regards to this topic, but none of them have enabled me to build a statically linked exe.
In my release configuration (x64) I have the following:
Configuration Properties -> General : Use of MFC - Use MFC in a Static Library
Configuration Properties -> C/C++ -> Code Generation : Runtime Library - Multi-threaded (/MT)
Configuration Properties -> Linker -> Command Line : Additional Options - I have all the required Windows libs "kernel32.lib", etc. (as use of MFC removed them from the "All Options" window above)
Configuration Properties -> Manifest Tool -> Input and Output : Embed Manifest - No
Note that in Configuration Properties -> Linker -> Input there are 5 lib files that I'm using in my project, eg glfw3.lib and I'm using Full optimisation (/Ox).
After building the project and running the exe myself I receive errors "The code execution cannot proceed because glfw3.dll was not found..." etc.
Using dependencywalker I can see that it needs the dlls associated with the libs, which it of course cannot find.
Am I misunderstanding how to do this or is there something else that might be wrong?
(I'm using Visual Studio 2017)
Yes, it appears you have a slight misunderstanding.
If something is offered as a DLL, then it is meant to be used as a DLL. There may be some way to incorporate a DLL into an executable, but it would be a hack. That's not how things are supposed to work.
The lib file that you are linking against exists simply in order to provide you with functions that you can link against, and these do nothing but delegate to the corresponding functions in the dynamically loaded DLL. Without it you would have to locate each entrypoint of the DLL yourself, which would be perfectly doable, but a bit cumbersome.
So: you must either find a version of glfw3 which is packaged as a statically linkable library (I have no idea whether one exists) or live with the fact that your .exe will need to be shipped together with glfw3.dll.
Related
I am trying to use ICU Unicode in my C++ Project.
I have downloaded the libraries from here, and then linked them by:
Adding the lib64 directory to Properties -> Linker -> General -> Additional Library Directories
Adding the names of all the .lib files into the Input tab.
I then #include "ucnv.h", and the build and run.
The program builds fine, but I get this error message saying I need to put the DLL next to the exe.
I do that, and it runs fine. My questions is
How do I statically link ICU to my project?
What I have tried
I have tried downloading the Master from github, and opening the allinone.sln file, and then setting the following:
Release and x64
Changing the output from DLL to Static Lib
Adding U_STATIC_IMPLEMENTATION to all of the project-preprocessors
I then rebuild, and then add each one of the projects release directories to the Additional Library Directories section of my projects properties, and then also adding the names of the libraries to the Input Section.
Now this actually works for UTF-8, however, for another encoding such as Big-5 most of the functions (and basically all essentials) return NULL.
Also, another reason for a static library is because the DLL I downloaded is over 16MB, which is way too big. On ICU docs they even say that they recommend static linking to reduce size (by removing unneeded)
I am trying to use ICU Unicode in my C++ Project.
I have downloaded the libraries from here, and then linked them by:
Adding the lib64 directory to Properties -> Linker -> General -> Additional Library Directories
Adding the names of all the .lib files into the Input tab.
I then #include "ucnv.h", and the build and run.
The program builds fine, but I get this error message saying I need to put the DLL next to the exe.
I do that, and it runs fine. My questions is
How do I statically link ICU to my project?
What I have tried
I have tried downloading the Master from github, and opening the allinone.sln file, and then setting the following:
Release and x64
Changing the output from DLL to Static Lib
Adding U_STATIC_IMPLEMENTATION to all of the project-preprocessors
I then rebuild, and then add each one of the projects release directories to the Additional Library Directories section of my projects properties, and then also adding the names of the libraries to the Input Section.
Now this actually works for UTF-8, however, for another encoding such as Big-5 most of the functions (and basically all essentials) return NULL.
Also, another reason for a static library is because the DLL I downloaded is over 16MB, which is way too big. On ICU docs they even say that they recommend static linking to reduce size (by removing unneeded)
I had a C/C++ Visual Studio 2013 Community Edition project that was defined to generate a DLL, and I'm having a lot of misery with "undefined symbols" which I wanted to use in another project, so I decided to see what it would give if I changed the project settings so that it would generate a static library instead.
So in the Properties window of the project I went to
Configuration Properties > General > Project Defaults > Configuration Type
and set the Configuration Type to Static Library
The target extension is .lib.
When I do a rebuild I still get a fresh dll file in my Release folder, as well as a lib, and the DLL file is much bigger than the lib file. This makes the lib file look like an "export lib" file and it looks like nothing has changed.
This still happens if I stop and restart Visual Studio.
Am I missing something or does this look like a bug to you?
In Configuration Properties - C/C++ - Runtime Library change setting to Multi-threaded (/MT) for Release configuration and to Multi-threaded Debug (/MTd) for Debug configuration.
Also, check Configuration Properties - General - General - Target extension is set to .lib.
Check settings for all configurations (Release and Debug if you use them).
Why have you changed your project type? If you need DLL, build DLL. Post exact errors received during DLL compilation. Perhaps you missed some dllexport/dllimport declspecs.
Regarding .lib: are you sure, that DLL is generated during build? Perhaps it is the output from previous (DLL) configuration? Have you tried to compile test app using this .lib? Perhaps it is valid and compiled properly?
Another matter: have you removed all dclspecs from function signatures after project type change? When building static library, none of them are applicable.
Ok so I made a small multithreded program in c++, when I compile it on one machine it works fine but when I try to run it on another machine it says "missing msvcp123D.dll".
I went looking around the forums and found some good info on this one. The solution was to create static links to the needed libs.
Project Properties -> General -> Use MFC in a Static lib
Project Properties -> Input -> additional dependencies -> ? now I would like to ask what libs do I need to add here in order to make this work on Windows 7 , 8, 8.1 machines
Thank you all for your time.
msvcp123D.dll is the DEBUG runtime. Build a release version and install the VC2013 redists on the target machines to get rid of this error.
Alternatively you can statically link the run time in which case you'll just need your own binaries (even if its a debug build).
Edit: To statically link the runtime right click the vcxproj file and go to properties, then under C/C++ code generation change "Multithreaded Release/Debug DLL" to "Multithreaded Release/Debug". The options with out "dll" in the name are the static versions.
I am configuring my Projects to build with x86 and x64 bits, in order to do that I had to change the Target Machine for the different Configurations.
I was trying to find where to set the Target Machine for my Native C++ Libraries and I found this post.
However I don't have a Linker in the Native C++ Library projects, I have the "Configuration Properties -> Linker -> Advanced -> Target Machine" option in the C++/CLI projects only.
In the Native C++ Library projects I have a "Librarian" section. I searched and I found that the Target Machine is in: Configuration Properties -> Librarian -> General -> Target Machine.
The Librarian section seems to have less options than Linker.
Are the Librarian and the Linker section the same? On the documentation I searched on google I only see Linker mentioned.
Maybe I have something configured wrong? Or in this post the answer didn't refer to Native C++?
Are the Librarian and the Linker section the same? On the documentation I searched on google I only see Linker mentioned.
They are almost the same. Option Librarian is enabled when your project is going to be a static lib. Option Linker is for executables and dynamic (link) libraries (dll).
Dynamic libraries will be linked dynamic to the executable you are building, which means the dll have to be around while execution. Static libraries on the other hand will be part of the executable. Static libraries mustn't be linked to some dynamic lib, since the linkage should be done while generating the executable. Otherwise it would cause ambiguity. This is why the Librarian options are reduced. (e.g. there is no Input options).
Maybe I have something configured wrong? Or in this post the answer didn't refer to Native C++?
The project from the linked post generates a dll (dynamic link library), not a static lib. Check your settings in Configuration Properties -> General -> Configuration Type.
You see the Librarian section when you created a static library project. Do beware that such a project is incompatible with code built with the /clr option, managed code is linked at runtime, not build time. Trying to use such the .lib file gives pretty hard to diagnose linker errors when you try to build an assembly. It is okay if you use it for pure native code, the kind built without /clr in effect.
There's very little to a .lib file, it is just a bag of .obj files. Think of it as a .zip archive with a cr*ppy compression rate. The lib.exe utility is there to get .obj and .lib files added and removed from the .lib, think of it as winzip.
So there are indeed very few settings in the General section, there's just not much to lib.exe. Pretty much a one-to-one mapping to the command line options that lib.exe takes. The /MACHINE option (aka Target Machine setting) is not required, it is fixed by the compiler you used. It is documented as:
However, in some circumstances, LIB cannot determine the machine type and issues an error message. If such an error occurs, specify /MACHINE.
So scratch that idea. It is entirely locked in by the Platform selection you used for your project. Standard ones in VS are Win32 to generate 32-bit code and x64 to generate 64-bit code.