I am importing a Visual Studio 2008 VC++ project into VStudio 2010. I am using Object arx application, where I need to include their library files. The issue right now is that the library files from the previous version are getting included but not the current version, whereas if I open a new sample project in VStudio 2010, it should include the library files of the current version.....
Any help regarding the same will be highly appreciated....
You can't safely link a Visual Studio application to libraries built with a different compiler version. Such attempts always lead to a lot of conflicts and mismatches between different versions of system libraries that both your application and external library depend on.
So, the solution for your problem would be to get a set of ObjectARX library binaries built with Visual Studio 2010. Or rebuild them from source, if it is available.
Also beware of building with the same compiler version, but different options (Multithreaded/Single-Threaded runtime, Debug/Release, static/DLL runtime, iterator debugging level for STL, etc). Such mismatches don't always lead to link-time failures (VS2010 improved its checks a bit, though), but are very likely to cause mysterious crashes in runtime.
Related
I have .obj files from Visual C++ 6.0 (1998) that I would like to use as-is in Visual Studio 2015 projects to avoid recompiling.
1) Is this possible?
2) If so, how do I do it?
These are built as single-thread (/ML or /MLd compiler option). VS15 C++ appears to offer only multi-thread models, with Linker library clashes I have not been able to resolve. Even a dirt-simple multi-thread VC++ test function will not link. What am I doing wrong??
It seems to me unlikely that Microsludge would invalidate these earlier formats.
I have tried all VS15 settings and options I can think of and find, including adding VC++ libraries in the Linker and various \NODEFAULTLIB placements. The Linker can recognize the function in the .obj but then throws a variety of undefineds...
If, instead of using the existing .obj, I add the source code to the VS15 project, all is well....
I recently updated my Visual Studio version to the latest (mostly because of an automatic update rather than me willingly doing so). This proceeded to break my compiler when linking in third party libraries that were built using 15.2 instead of the current version of 15.3. The error I'm seeing is:
"Library_Name_here.lib" was created with an older compiler than other objects; rebuild old objects and libraries
I am looking for either ideas for solutions to avoid a re-compile of these libraries, but if one does not exist, I am looking for a way to compile the libraries to be version agnostic to not have to keep recompiling every time that vs updates.
It is not a good idea to mix and match code (object files or static libraries) compiled by different versions of the compiler in the same binary.
To quote MSDN on that:
To avoid run-time errors that are difficult to detect and diagnose, we
recommend that you never statically link to binaries that were
compiled by using different versions of the compiler. Also, when you
upgrade an EXE or DLL project, make sure to upgrade the libraries that
it links to. If you're using CRT (C Runtime) or STL (Standard Template
Library) types, don't pass them between binaries (including DLLs) that
were compiled by using different versions of the compiler. For more
information, see Potential Errors Passing CRT Objects Across DLL
Boundaries.
The solution is therefore to recompile all third-party static libraries with the new compiler.
I also had issues few months ago when i upgraded VS2015 to VS2017 and one of my big project that i was running on visual studio 2015 stopped working. That project had several class libraries and external DLLs added.
So what I did was, Uninstalled the upgraded version of visual studio 2017 and re-installed the complete visual studio 2017 from MSDN website (selecting the default selection of features). And then i loaded my Project in VS2017 fresh copy and added the reference of all external libraries and it worked.
I suggest you to try the same
This is a shot in the dark, based on this other SO answer: Error C1047: Object file created with an older compiler than other objects
Recompile the other library without link time code generation enabled (/GL and /LTCG). With it enabled the library expects the linker to do most of the compiling, and you cannot expect one version of the compiler to finish the compiling another version started.
Do not disable it in your active project, as it improves performance significantly. Just in the library.
Major compiler versions may still require rebuilding the 3rd party library, but not minor.
You can do this from within VS2017. It allows you to use tool sets going all the way back to VS2008
See this for details!
https://blogs.msdn.microsoft.com/vcblog/2016/02/24/stuck-on-an-older-toolset-version-move-to-visual-studio-2015-without-upgrading-your-toolset/
Hope that helps!
I'm trying to get a better grasp on the CRT library options in Visual Studio 2013 (C++ -> Code Generation -> Runtime Libary) and how to know which option to select (and when to change the default).
From MSDN:
A reusable library and all of its users should use the same CRT library types and therefore the same compiler switch.
So, my understanding is that if you are linking with a third party library, you should use the same CRT version that was used to build the library. Whoever built the library should specify what CRT option was used in the build.
Is there a way to determine which CRT version was used just by looking at the .lib file?
More importantly, how would you decide which option to use if you aren't linking with any third-party libraries? When would you consider changing the default?
Short answer:
So, my understanding is that if you are linking with a third party
library, you should use the same CRT version that was used to build
the library. Whoever built the library should specify what CRT option
was used in the build.
That is the least error-prone option. It is possible to mix runtimes, but you can run into unexpected bugs if you do so.
Is there a way to determine which CRT version was used just by looking
at the .lib file?
I don't know about the .lib on its own, but if the third party code has a DLL or EXE, you can see what CRT DLL(s) it depends on using the Windows Dependency Walker tool.
If it's a static library, and your code's CRT choice is mismatched, you'll see warnings when you build.
More importantly, how would you decide which option to use if you
aren't linking with any third-party libraries? When would you consider
changing the default?
For the simplest possible deployment, statically linking is best; you can just ship the executable on its own and it will run. For larger projects, where you have multiple EXEs and DLLs, your code size will be bigger if you statically-link. It would also be preferable to be sharing the same CRT code if you have multiple modules (EXE plus 1 or more of your own DLLs) in the same process.
More detail (based on blog post I wrote previously):
The Library Variants
There are four variants of C/C++ runtime library you can build your code against:
Multi-threaded Debug DLL
Multi-threaded DLL
Multi-threaded Debug
Multi-threaded
You can select which library you’re using by right-clicking on your project in Visual Studio and selecting Properties, clicking the Code Generation option under C/C++ on the dialog that pops up, and going to the Runtime Library property.
Remember that this setting is per-configuration, as you’ll want to choose a Debug runtime library for a Debug configuration, and Release runtime library for a Release configuration.
What’s the difference?
The DLL runtime library options mean that you link dynamically against the C/C++ runtime, and for your program to run, that DLL will need to be somewhere your program can find it (more on that later).
The options not mentioning DLL (Multi-threaded Debug and Multi-threaded Release) cause your program to be statically-linked against the runtime. This means that you don’t need an external DLL for the program to be run, but your program will be bigger because of the extra code, and there are other reasons why you might not want to choose it.
By default, when you create a new project in Visual Studio, it will use the DLL runtime.
The multi-threaded in the runtime names is a legacy of when there used to be both non-thread-safe and multi-threaded C/C++ runtimes. You’ll always be using a multi-threaded runtime with modern Visual Studio, even if your own application is single-threaded.
Deploying DLL Runtimes
If you’re linking against the DLL runtimes, then you’ll have to think about how to deploy them when releasing your program (to Test, and to your customers).
If you deliver Debug builds to your Test team, make sure you provide the Debug variant of the DLL runtimes too.
Also, don’t forget to get the right architecture (e.g. x86 vs x64).
Redistributable Installers
Microsoft provide redistributable packages that install the Release (but not the Debug) DLLs. These can be found easily enough by searching for something like Visual C++ Redistributable 2013 (substituting the Visual Studio version for what you need). You can also go straight to Latest Supported Visual C++ Downloads on Microsoft’s website.
These redistributables packages are executables, and you can call them from your program’s installer (or you could run them manually for setting up a test environment). Note that there are separate redistributables for x86 and x64.
Merge Modules
If you’re building an MSI installer, you can merge the Merge Module for the C/C++ runtime you’re using into your installer package. These merge modules are typically found in C:\Program Files (x86)\Common Files\Merge Modules. For example, the x86 C/C++ runtime’s merge module for Visual Studio 2013 is called Microsoft_VC120_CRT_x86.msm.
Note that the version numbers in these merge module names are not the year-based product versions, but the internal version numbers. This table on Wikipedia shows the mapping between the version numbers for avoidance of confusion.
Unlike the stand-alone executable redistributable installers above, the merge modules also come in Debug variants.
Some versions of Visual Studio have support for a Visual Studio Installer project type (under the Setup and Deployment category in Other Project Types), and if you include the output from your program’s projects in one of these installers, the merge modules for the runtime will be included automatically. You can also use this as a trick to get an installer that will install the Debug runtimes for internal testing purposes (any dummy C/C++ project will do, it doesn’t have to actually install your program).
Copy From Redist Folder
You can also just copy the DLLs from the redist folder in your Visual C++ installation into where your program is installed. For example, for Visual Studio 2013, you’ll find the x64 C/C++ runtime libraries somewhere like C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\x64\Microsoft.VC120.CRT\.
The debug variants can be found somewhere like C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\Debug_NonRedist.
(Adjust paths as appropriate for your Visual Studio version and installation location).
Mixing C/C++ Runtimes
In an ideal world, you would use the same C/C++ runtime library variant (Debug vs Release, DLL vs statically-linked), and all from the same version of Visual Studio, for all libraries being linked into your program.
If you do mix runtimes, you may get linker errors, your program may simply fail to run at all, or worse still, it may seem to be working but crash or give the wrong result only in some cases.
Ignoring Default Libraries
A common scenario is that you only have the Release version of some third-party library, but you still want to be able to build the Debug variant of your own code using this library. Another scenario is that you have a library that uses the static C/C++ runtime and you want the DLL version in your program, or the reverse.
If the third-party library is C code then you’ll probably be able to get away with this and have it actually work, using the /NODEFAULTLIB linker option.
If the library is C++ code, you are probably out of luck as too much of the generated code is tied to symbols in a particular runtime.
These are the different library names:
LIBCMT.LIB: Statically-linked Release runtime (a.k.a. Multi-threaded)
LIBCMTD.LIB: Statically-linked Debug runtime (a.k.a. Multi-threaded Debug)
MSVCRT.LIB: Dynamically-linked Release runtime (a.k.a. Multi-threaded DLL)
MSVCRTD.LIB: Dynamically-linked Debug runtime (a.k.a. Multi-threaded Debug DLL)
Remember, the runtime libraries you want to ignore are the ones that the third-party code is using, i.e. it will be different from the library that your own program is using. If you look at your build output you will be prompted to choose the right one anyway, e.g.:
LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library
You can specify the library to ignore by right-clicking on your project, selecting Properties, clicking the Input entry under Linker and adding the runtime library name into the entry.
Crossing Module Boundaries
You can also run into C/C++ runtime mismatch problems in more subtle ways across module boundaries (between an EXE and a DLL it loads for example).
For example, data structures in the C library may be defined differently by different runtimes. I’ve seen this cause crashes in programs that used a DLL that made use of a FILE* in its API. A file is opened in one module using one C runtime, and interacted with by another module which has a different, incompatible implementation. Safer options would include passing Windows API HANDLE objects for things like this, or else wrapping up the file interactions in a way that is runtime-agnostic.
Different runtimes also use their own memory heap for allocations. If an object is allocated in one module on one heap, but deallocated in another module, a crash is likely to occur if the C/C++ runtimes are mismatched. This only applies of course to allocations using the C or C++ runtime such as malloc or new. If the default Windows process heap is being used everywhere, for example, everything is fine.
Note that if the modules statically link against the C/C++ runtime, they will have this problem even if it was the same variant of the runtime they linked against, because there will still be two different runtimes with their own memory heaps in play. Therefore, you will want to use the DLL C/C++ runtime in such circumstances.
It would also be wise to use the (same version of) DLL runtimes in each module if runtime-implemented functionality like exceptions or classes with vtables cross the module boundaries, though some combinations of mismatch may work in practice.
I'm developing an application in Visual Studio 2010. The debug and release executable works fine on my PC, but when I try to run it on another PC< i get the MSVCR100.dll not found error.
The problem is described here:
http://www.rhyous.com/2010/09/16/avoiding-the-msvcr100-dll-or-msvcr100d-dll/
Searching on the web, reveals that you need to have the Visual C++ redistributable installed.
Is there a way to build the project so that the VC++ redistributable is not required ?
As noted in the page you linked, you can choose to statically build the libraries into your app, which guarantees they are always included. This is done in the project's properties -> C/C++ -> Code Generation -> Runtime Libraries (select multi-threaded or debug, without DLL).
If you don't want to statically link these, you can include the runtime DLLs with your program; this is useful for sharing a particular version between your modules and only yours, but installing the proper redistributable (and allowing upgrades, for security reasons, etc) is much preferred.
When possible, you should use the DLL from the system, to allow future security patches to apply to your program. The redistributable is a few MB and compatible with a variety of OS versions, so asking users to install it or even including it in your installer is not usually a problem.
To avoid using them entirely is perhaps possible, but slightly less feasible. You would have to avoid any code they provide, and MSVCR is the equivalent of libc; most programs use features from it and it's a standard part of the system.
Yes, you can links CRT statically (check project settings). But it will cause bigger executable size.
How do you tell Visual C++ Express 2008 to statically link runtime libraries instead of dynamically? My exes do not currently run on computers w/o some sort of VS installed and I would love to change that. :)
Sorry, I do not have VC++ Express to test, but in Standard edition I use Project Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library. Dll and Dll Debug are for dynamic linking.
Are you 100% sure that you want to do this? Please consider that if you do and there is a security vulnerability found in the runtime library, Microsoft will not be able to patch your application via Windows Update.
Another solution is to package the Visual C++ Runtime Redistributable with your application. It installs very fast and does not require Visual Studio. It is also important to note that you should not distribute code linked against the debug runtime libraries as those do require Visual Studio. See this blog post for more information on packaging the redistributable.
EDIT: With that said, it's up to you. My point is simply that you should not disregard dynamic linking based solely on the idea that users must have "some sort of VS installed", which is not true.
See the answer to this question: How do I make a fully statically linked .exe with Visual Studio Express 2005 ?. It's for VS2005 Express but the answer still holds.
For the C-runtime go to the project
settings, choose C/C++ then 'Code
Generation'. Change the 'runtime
library' setting to 'multithreaded'
instead of 'multithreaded dll'.
If you are using any other libraries
you may need to tell the linker to
ignore the dynamically linked CRT
explicitly.
You can install the C runtime redist on the target machine and you're executable would run there as well with dynamically linked C runtime.
(Oh sorry, that had already been mentioned).