I am using a library which is compiled in visual studio using the multibyte character set option.
The library is being used in a MFC project which is using the Unicode character set.
At compile and link time I am not running into any issues.
Are there any runtime "gotchas" that I shoushould aware of?
Related
I am in the process of porting a library to Xbox Series X console, and openssl (and by extension libcrypto) is one of dependencies of the library.
Openssl project is generated using Visual Studio 2019 from Makefiles. It mostly works after some work, and compiles using Xbox toolchain, but i have unresolved external symbols during linking. Mostly CRYPTO_THREAD_xxx and InterlockedExchangeAdd ones. I have noticed that my VS project only has crypto/threads_none.c in solution explorer, but i have OPENSSL_THREADS defined. Therefore, these functions never get into the final object file, as threads_none.c defines them only if OPENSSL_THREADS is not defined.
How can i generate this project so that it has same files as windows library? Namely, i would love it to use threads_win.c, and there are possibly other differences as well. I have zero idea how platform configuration works in openssl, it seems to use some proprietary system which is dark and unknown magic to me, held together with perl scripts.
After reinstalling Visual Studio 2010, I recompiled the code and encountered the following error:
Error 'LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt'
A solution mentioned that the lib file is incompatible and I need to install Visual Studio 2010 SP1. I did that, and now it has been solved.
I am wondering how can I check whether a lib file is created by SP1 or not?
I tried dumpbin, but I cannot find the version in its result.
It was not an incompatibility with your LIB file that caused the problem here, so checking the version of the linker that created it would not be a solution anyway.
The issue is that cvtres.exe (used internally by the linker toolchain) depends on a particular DLL (msvcr100_clr0400.dll) shipped with VS 2010 RTM. When you update to a later version of the .NET Framework (e.g., by installing .NET 4.5 or installing a later version of VS), this DLL is replaced. That stops cvtres.exe from working.
The reason why installing VS 2010 SP1 fixes it is because it actually modifies the cvtres.exe application to break the dependency. And now that all pieces of the linker toolchain work, you can compile and link the code without error.
Of course, there are other problems you can have when you start mixing libraries created by different versions of the compiler and/or linker. They aren't guaranteed to create 100% compatible output, so mixing them is not supported (at least not between major versions, I'm uncertain about how this rule applies to service packs).
In general, it's best to just recompile all libraries whenever you update your build system. The only time you wouldn't do this is if you didn't have the source code, in which case, you need to be very careful about updating your build system, lest you introduce gratuitous incompatibilities.
As far as determining the version of the linker that prepared a particular binary, using dumpbin.exe (included with the SDK) is exactly the correct approach. For static libraries, run the following command from the Visual Studio SDK Command Prompt:
dumpbin /rawdata:1 MyLibrary.lib
You'll see the assembly manifest, which will include the full path to the compiler used to build the library as well as the version of the CRT that it depends upon.
For dynamic libraries (i.e., DLLs) and executables, run the following command:
dumpbin /headers MyApp.exe
Look under the "Optional Header Values" section (not actually optional) for the version of the linker, along with a timestamp of when it was generated.
Note that you're very unlikely to find this information in release builds of a library or binary.
I'm taking a 32-bit source library and compiling on a 64-bit platform and getting alignment issues (not only 32-bit vs 64-bit but also character set as well).
I want to place all the 64 bit configurations into a "Win64" folder and the 32-bit configurations into a "Win32" directory.
I'm looking into some guidance for modifying the project file so that the target library and dll filenames will be in terms of the configuration.
Examples:
Win64/testrunner_x64d.lib -- Library, debug, 64-bit platform, ASCII
character set.
Win64/testrunner_x64ud.lib -- Library, debug, 64-bit platform,
Unicode character set.
Win32/testrunner_x32d.lib -- Library, debug, 32-bit platform, ASCII
character set.
Win32/testrunner_x32ud.lib -- Library, debug, 32-bit platform,
Unicode character set.
I'm new to using configurations in Visual Studio 2010 and also porting an existing project.
For the character setting, go to "Configuration Properties"->"General"->"Project Defaults"->"Character Set", chose the one as you wish.
For the lib's name for different configuration, you can set it via "Linker"->"General"->"Output File"
Can i replace mfcs90.lib with mfcs100.lib while converting VS2008 project to VS2010 project
Yes you can and should. Looking around I have found some documentation that may help and explain a bit more about what you need to do.
These MFC link libraries are lightly documented by Microsoft's TN033 Tech Note: http://msdn.microsoft.com/en-us/library/hw85e4bb.aspx
A quick summary about the mfcsxxx.lib files is: The MFCSxx[U][D].LIB libraries are used in conjunction with the MFC shared DLLs. These libraries contain code that must be statically linked to the application or DLL.
* The "U" designates that the library is built for Unicode.
* The "D" designates that the library is built for Debug.
* If the number in the library is 90, then it's compiled with and for Visual Studio 2008 (VC++ 9.0)
* If the number in the library is 100, then it's compiled with and for Visual Studio 2010 (VC++ 10.0)
Note that while the mfcsxxx.lib files have code that is statically linked to the output binary, they are used in conjunction with the DLL versions of MFC - when statically linking MFC, the [nu]afxcw[d].lib libraries are used (where "n" or "u" determines whether or not the library is Unicode, and "d" is used in Debug builds).
I am reading Charles Petzold's Programming windows. 5th Edition. And there is a statement to Windows.h file.
It said.
There is a WINNT.H file included in Windows.h file.
And the WINNT.H file used to define Unicode support.
But I can't find it in Visual Studio 8.0 Windows.h file.
And the file (WINNT.H) is not existing in Windows.h in VS 8.0, How can the Unicode support function be realized?
If you have the Visual C++ component of Visual Studio installed (i.e. if you can compile .cpp files), then you have WINNT.H. As well as Windows.h (which implicitly #include's WINNT.H for all Win32 targets).
It should be under "\includes" in your MSVS install directory.
In earlier versions of MSVS, 8-bit ASCII was the default, and you had to explictly "#define _UNICODE" (e.g. as a compile option). Newer versions (I believe starting in MSVS2005, but certainly now in MSVS2008 and MSVS2010), 16-bit Unicode is the default.