msbuild - static lib compilation failed after adding resource file to project - c++

I have a C++ library which is compiled as dynamic and static library. Recently I add resource version file to source. The dynamic library compilation works fine, but static library compilation started failing for 64 bit target with following error:
LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
x64\Release\dllmain.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
Following is my compilation script:
#ECHO OFF
call "%VS140COMNTOOLS%"\\vsvars32.bat
SET SourceDir=D:\Projects\MySampleLib
SET TargetDir=D:\Projects\Packages
ECHO 32 bit MySampleLib .LIB compilation VS2010
msbuild.exe %SourceDir%\MySampleLib\MySampleLib.vcxproj /t:Clean;Rebuild /p:Configuration=Release;Platform=Win32;ConfigurationType=StaticLibrary;PlatformToolset=v100
ECHO 64 bit MySampleLib .LIB compilation VS2010
msbuild.exe %SourceDir%\MySampleLib\MySampleLib.vcxproj /t:Clean;Rebuild /p:Configuration=Release;Platform=x64;ConfigurationType=StaticLibrary;PlatformToolset=Windows7.1SDK
The error occurs when Lib.exe command tries to link the MySampleLib.res
Note: The error only appeared after I added the resource file. I don't want to add the resource file to static libs.

I finally fixed the issue by modifying the following .vcxproj entry
<ItemGroup>
<ResourceCompile Include="MySampleLib.rc" />
</ItemGroup>
to
<ItemGroup Condition="'$(ConfigurationType)'!='StaticLibrary'">
<ResourceCompile Include="MySampleLib.rc" />
</ItemGroup>
This prevented linking of resource file in static compilation.

Related

Unable to embed Pdfium - unresolved external symbol

After successfully building Pdfium as per Google's docs, I created a new C++ console app with VS2022 and tried to embed .lib resulting from Pdfium build but, it results in several unresolved symbols which, I guess, should be included in standard C++. As an example, here is two of the unresolved symbols:
fx_string.obj: error LNK2001: unresolved external symbol "void __cdecl std::Cr::__libcpp_verbose_abort(char const *,...)"
fpdf_parser_utility.obj : error LNK2001: unresolved external symbol "public: class std::Cr::basic_ostream<char,struct std::Cr::char_traits<char> > & __cdecl std::Cr::basic_ostream<char,struct std::Cr::char_traits<char> >::write(char const *,__int64)"
Steps taken:
build Pdfium following docs steps using below args.gn:
use_goma = false
is_debug = false
pdf_use_skia = false
pdf_enable_xfa = false
pdf_enable_v8 = false
pdf_is_standalone = false
is_component_build = false
pdf_is_complete_lib = true
Created a simple C++ console app with following content (copied from Getting started):
#include <iostream>
#include "../PDFium/public/fpdfview.h"
int main()
{
std::cout << "PDFium test!\n";
FPDF_LIBRARY_CONFIG config{};
config.version = 2;
config.m_pUserFontPaths = NULL;
config.m_pIsolate = NULL;
config.m_v8EmbedderSlot = 0;
FPDF_InitLibraryWithConfig(&config);
FPDF_DestroyLibrary();
return 0;
}
Copied Pdfium's public folder and resulting .lib file into a separate folder of the project, added necessary fields for linker and set C++ language spec to stdc++20; below, the corresponding tags in .vcxproj
<!-- other tags -->
<ClCompile>
<!-- other tags -->
<LanguageStandard>stdcpp20</LanguageStandard>
<LanguageStandard_C>stdc11</LanguageStandard_C>
</ClCompile>
<!-- other tags -->
<Link>
<SubSystem>Console</SubSystem>
<GenerateDebugInformation>true</GenerateDebugInformation>
<AdditionalLibraryDirectories>$(SolutionDir)PDFium\x64</AdditionalLibraryDirectories>
<AdditionalDependencies>PDFium.lib;%(AdditionalDependencies)</AdditionalDependencies>
</Link>
(Unsuccessful) Tests did
Tried to compile PDFium with and without pdf_is_complete_lib = true, and thus, linking also single .objs, and v8 and xfa support
Tried to compile with Microsoft's clang-cl instead of MSBuild (the one provided by Visual Studio's Native Development pack)
Tried to compile with depot tools's clang-cl (currently, version 16.0.0)
Tried several options found here and there on SO and on internet
Any help is appreciated. Thanks in advance.
After days of failures and (vain) research, I finally found the solution, posted here for future reference.
TL;DR;
Depending on flags set in args.gn, Pdfium will need at least the following to successfully build and start the Getting Started example:
if is_component_build = false and, thus pdf_is_complete_lib = true, .obj files built from libc++ and winmm.lib
if is_component_build = true and, thus pdf_is_complete_lib = false, all .dll resulting from compilation, i.e.:
absl.dll
icuuc.dll
libc++.dll
partition_alloc.dll
pdfium.dll
zlib.dll
Read also the important note below which tries to explain the difference between the two flags.
Long description
As per docs, once .ninja files has been generated as result of gn args <out_dir>, it can be seen which .obj, .lib and .dll files are needed to build pdfium_unitests.exe. Comparing those with the ones used to generate pdfium.lib (or pdfium.dll depending on flags, see below), it can be spotted the required libraries.
With is_component_build = false and pdf_is_complete_lib = true:
start default compilation with ninja -C <out_dir>; this also builds libc++;
generate pdfium.lib via ninja -C <out_dir> pdfium (will only execute a link step)
(optionally) generate a libc++.lib using depot tool's lld-link which will contain all .obj files from compilation of libc++:
"C:\path\to\pdfium\third_party\llvm-build\Release+Asserts\bin\lld-link.exe" /lib /OUT:libc++.lib /nologo /WX /ignore:4221 <space-separated list of .obj files in C:\out_dir\obj\buildtools\third_party\libc++\libc++>
link pdfium.lib, all libc++'s .obj files in C:\out_dir\obj\buildtools\third_party\libc++\libc++ (or, libc++.lib from previous step), winmm.lib in your project; e.g.:
<Link>
<!-- other options -->
<AdditionalDependencies>pdfium.lib;libc++.lib;winmm.lib;%(AdditionalDependencies)</AdditionalDependencies>
</Link>
With is_component_build = true and pdf_is_complete_lib = false:
start compilation with ninja -C <out_dir> pdfium; will compile all the necessary .dlls along with .pdb and .lib files and put them in out_dir
link pdfium.lib in your project and copy emitted .dlls in output directory; assuming emitted files are in C:\pdfium\result, project's .vcxproj will look like this:
<!-- ... -->
<Link>
<AdditionalLibraryDirectories>C:\pdfium\result</AdditionalLibraryDirectories>
<AdditionalDependencies>pdfium.dll.lib</AdditionalDependencies>
</Link>
<!-- ... -->
<PostBuildEvent>
<Command>cmd /c "robocopy C:\pdfium\result $(OutDir) /xf *.lib & if %errorlevel% geq 8 exit 0 else exit %errorlevel%"</Command>
</PostBuildEvent>
<!-- ... -->
Note: the files you'll need are listed in tl;dr; section.
Note 2: used robocopy because is more efficient than xcopy. Also, check on exit code is needed because of the value returned by robocopy
Important note
pdf_is_complete_lib and is_component_build will set, respectively, /MT and /MD flags during compilation.
Although might not seem a problem, MSBuild will complain if the two types are mixed and thus, you'll need either to recompile Pdfium or change the way your code is generated via Project Properties > C/C++ > Code Generation > Runtime Library.
For more information see Google docs, Microsoft docs on flags and linker warning and, eventually, this SO question which can help in choose the code generation that most suits your needs.

C++Builder 10.4/11: Help wanted to resolve fatal error "Invalid object file 'altsvc.o'" when compiling 64-bit Windows application

I am attempting to port a 32-bit program to 64-bit, using the CLANG compiler within C++Builder 10.4/11. However, when C++Builder attempts to link the EXE it generates the following error message:
C:\Program Files (x86)\Embarcadero\Studio\21.0\bin\CodeGear.Cpp.Targets(3988,5): error : Fatal: Invalid object file 'altsvc.o'
I cannot find a file called "altsvc.cpp" anywhere in my source files or in the C++Builder library file folders. It is not listed in the executable's project (.cbproj) file either.
Has anyone encountered this error before and know what causes it?

mismatch detected for 'vccorlib_lib_should_be_specified_before_msvcrt_lib_to_linker': value '1' doesn't match value '0' in msvcrtd.lib

I have a C library project for UWP. There are some C files which are calling C++ WINRT functions defined in CPP file.It is compiling successfully and generating a library file(LIB). I am compiling in Visual Studio 2015 with update 1 and target platform is 10.0.10240.0
But, I want to generate DLL instead of LIB file. Here's the changes I did to change the project so that it generates DLL instead of LIB.
Try1:
So, In the startup project, In Configuration Properties => General I change Configuration from Static Library to Dynamic Library.
And in all the project, I changed from Multi-threaded Debug(/MTd) to Multi-threaded Debug DLL(/MDd).
Try2:
Created a new project Windows Universal Project and added the all the files from the project creating LIB to this project. Still, I am getting the below errors.
Now, I am getting the errors
vccorlibd.lib(init.obj) : error LNK2038: mismatch detected for 'vccorlib_lib_should_be_specified_before_msvcrt_lib_to_linker': value '1' doesn't match value '0' in msvcrtd.lib(app_appinit.obj)
vccorlibd.lib(init.obj) : error LNK2005: __crtWinrtInitType already defined in msvcrtd.lib(app_appinit.obj)
msvcrtd.lib(initializers.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
Any Suggestions how to resolve this.
I had the same Issue and fixed it using the linker flags:
/nodefaultlib:vccorlib /nodefaultlib:msvcrt vccorlib.lib msvcrt.lib
for debug builds you can use:
/nodefaultlib:vccorlibd /nodefaultlib:msvcrtd vccorlibd.lib msvcrtd.lib
The standard /nodefaultlib did not work for me.
The following linker flags (for debug) did the trick in my case:
/defaultlib:'vccorlibd.lib' /defaultlib:'msvcrtd.lib'

QuantLib 1.5 compiling error cannot open file 'QuantLib-vc100-x64-mt.lib'

I have already installed boost library v1.57.0 (x64) via the binary file, which works properly under my VS2010Pro.
However, when I tried to compile the latest version (v1.5) of QuantLib, by opening QuantLib_vc10.sln file, for both 'Debug' and 'Release' under 'x64' in VS2010, I got something like:
QuantLib.vcxproj -> ...\QuantLib-1.5.\lib\QuantLib--x64-mt.lib
in the 1st project, then 18 failed build with the error:
LINK : fatal error LNK1104: cannot open file 'QuantLib-vc100-x64-mt.lib'
It is clear that the fatal error is due to the incapability of naming library with 'vc100' in the 1st project. But I don't know how to fix the problem.
Any suggestions? Thanks!
The version tag should be taken care of in the QuantLib.props file, which in imported in the project. From searching a bit, though, it looks like the VisualStudioVersion property (which we're relying on) might not be defined in VS10. Try editing QuantLib.props, and adding
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
</PropertyGroup>
before the other two PropertyGroups, and relinking the library (and please, let me know if this works so I can patch the file in the next release).

Link Error 'target machine "THUMB" requires "/WINDOWSCE"' on static library

I am moving a Embedded Visual C++ project to VS2005. When I compile the project I get this error: fatal error CVT1109: target machine "THUMB" requires "/WINDOWSCE" CVTRES. Goggling this just left me more confused. Most stated I needed to add the linker option /WINDOWSCE. My issue is there is no linker options in Configuration Properties for a static library.
I left out I am also getting this link error:
LNK1123: failure during conversion to COFF: file invalid or corrupt
Update The error above happens when the the output windows says it is 'Creating library...'. I believe this has to do with the resource file in the project. If I remove the rc file I can create the library. Why is the rc file causing the CVTRES error?
Finally Resolved I opened
Project Properties --> Configuration Properties --> Librarian --> Command Line
Than I added the following line:
/subsystem:$(CESubsystem) /MACHINE:THUMB
I would of sworn I tried that from the start, thank the heavens I found the solution hope it helps someone else.