Is there a way to link to the open scene graph libraries statically?
I compiled osg on windows 7, and it has both static and dlls, but I want to link statically so I don't have to rely on the dlls. The point is so that I can just carry the exe file for distribution and have other people test it without having to worry about the dlls being missing. I don't know what I have to change in the settings for it to link only to the static libraries.
I'm using visual studio 2010.
See the CMake option
DYNAMIC_OPENSCENEGRAPH
Set to ON to build OpenSceneGraph for dynamic linking. Use OFF for static.
Related
I have a solution which has two projects. One is a static link library project, and another is a console project for demo. Now I want to create a MFC project to replace the console project, what should I do to configure the MFC project.
the MFC project need to use some classes in the .lib project.
I have set MFC project as start project and depend on the .lib project.
My platform is win7 + vs2015.
Actually, the solution is EasyPR, you can get it here EasyPR.
Thanks for any help.
Setting the dependency to the static library is one step.
To compile the code you may need headers for the compiler. So the MFC projects may need settings for the compiler to define additional include paths.
You still need to configure the linker to use and find the library. To reference the library you may use a pragma comment lib. In the linker settings you may add an additional path for the libraries.
Or you may simply drag the lib into the solution explorer. The build mechanism will know how to treat a lib and will include it into the build process. The later will only work if you have 1 lib for release and debug.
If you have different libs for release and debug a advise you to use different names. You may adjust the project settings of the MFC program for debug and release differently.
When I launch .exe it gives error MSVCP120.dll is missing. How do I add statically link to project. Is it in Linker? Do I need to give path to MSVCP120.dll?
In general, you should not use static CRT linking as it creates a number of potential problems, security risks, and servicing concerns. You can require the VC++ REDIST package to be run (which requires admin rights) to install the 'system' version, you can use the VC++ MSM modules with your own MSI installer, or you can just use side-by-side deployment and put the DLLs in the same folder as your EXE.
See Redistributing Visual C++ Files
You can use static linking for Win32 desktop apps, but there's only a few places where such use is warranted (namely pre-installation utilities). The CRT settings are the same as other Visual Studio editions as part of the compilation as a command-line switch or a setting in the IDE under Project Properties / C/C++ / Code Generation to either "Multi-threaded (/MT)" or "Multi-threaded debug (/MTd)"
You cannot use static linking for Windows Store apps, Windows phone 8.x, or Xbox One apps.
I dont have visual studio 2008 installed.I am using 2012 and i rebuild this projects by cleaning.I checked the project settings and controlled the additional libraries and unfortunately I couldnt find any lib link has this name...in project just .h files of date_time are used but no lib linking. I configured new version of boost but STILL it wants this lib ? so is there any way I can solve this problem ?
With Visual Studio, boost use an auto linking system.
Special code in Boost header files detects your compiler options and
uses that information to encode the name of the correct library into
your object files; the linker selects the library with that name from
the directories you've told it to search.
date_time is one of boost modules that need a library (which is not header only).
So, you have to build them, using bjam (and --toolset=msvc-9.0), or retrieve them already built for your system.
Other option: disable auto linking. Just define
BOOST_DATE_TIME_NO_LIB
And link manually.
We have a project which has a multistage build system: it's split into modules consisting of multiple source files, and each module is compiled and partially linked into a single object file. Then these object files are linked together into the final program. (This approach is required for non-technical reasons.)
Currently we use gcc and binutils for this, and it's very easy there: ld -r will partially link multiple object files into one.
Unfortunately, we've now been faced with a platform for which there is no gcc/binutils support, only Visual C support. So I've been reworking the build system to use the native Microsoft tools. Unfortunately I have not yet found a way to do a partial link --- link.exe seems to only support outputting EXE or DLL files.
Does anyone know of a way to do a partial link in Visual Studio?
Note that .LIB libraries are not adequate. Neither is incremental linking. And this is all happening from the command line.
I have a communication library built on top of Qt and Google Protocol Buffers. It's currently being built with MinGW/GCC on Windows. My goal is to use the same library in C# on .NET, with the help of a thin wrapper on top using C++/CLI (bridging the unmanaged code with managed code).
I tried using the MinGW produced DLL directly in my C++/CLI project, but I keep getting linker errors (cant remember the error codes right now, but something about missing tokens and functions/signatures).
First question is: Should I be able to use the MinGW-produced DLL with the Visual Studio compiler/linker? Or do I need to compile the library again, using only VS compiler for all projects?
If I should be able to use the MinGW-produced DLL directly, how do I reference it in Visual Studio 2010? In project settings it seems to look for *.lib files, but I can't find any .lib files in the output of MinGW/GCC. It does produce *.a files, but it seems like Visual Studio don't handle this kind of file..
I should also mention that both Qt and protobuf are also compiled with MinGW. But I can of course recompile all the parts in VS 2010 if necessary.. Would have been nice to save the recompile time though, since our buildserver already has a working setup using MinGW.
The easiest way to use it would be by recompiling it with Visual Studio. This is when I am assuming C++ types and classes used in the interface you intend to use.
In case you have a C interface to this library you could dynamically load the library via LoadLibrary and use GetProcAddress to access those functions.
However it depends completly on the way how you intend to use the library.