Missing libcrypto.lib in CMake build of Poco project - cmake

The Poco Libraries can be really powerful and useful... but also stubbornly hard to build :-( I am now several days into a process of trying to upgrade from:
Poco 1.9.0, win32 build, including NetSSL_OpenSSL and Data/MySQL, on Windows 7, using MS Visual Studio 2015 successfully built via buildwin.cmd script from Windows Explorer since April 2018
to:
Poco 1.10.1, win32 and x64 builds, including NetSSL_OpenSSL and Data/MySQL (32-bit) or Data/PostgreSQL (64-bit), on Windows 10, using MS Visual Studio 2019, built via any means at all.
So far I cannot make the build process budge in any significant direction from my old build to my new target via any means... except possibly via CMake.
Since CMake appears to be the preferred way to build Poco, and nothing else (e.g. buildwin.cmd) works as expected, I am trying to rebuild the 32-bit DLLs so I can test with older proven components in my application. It looks promising. But the crypto build complains:
LINK : fatal error LNK1104: cannot open file 'libcrypto.lib' [S:\3rdparty\Poco-build32\Crypto\Crypto.vcxproj]
That's strange: in the entire Crypto.vcxproj file, there is no mention of libcrypto.lib at all, only libcrypto32MD.lib and libcrypto32MDd.lib. Why is it even looking for libcrypto.lib? Even so, if it is supposed to be finding libcrypto.lib, why doesn't it succeed when it is freshly installed in C:\Program Files (x86)\OpenSSL-Win32\lib and OPENSSL_ROOT_DIR is set to C:\Program Files (x86)\OpenSSL-Win32? What am I missing? I got to this point via:
cmake -HS:\3rdparty\Poco -B S:\3rdparty\Poco-build32 -G "Visual Studio 16 2019" -A win32
cmake --build s:\3rdparty\Poco-build32 --config RelWithDebInfo
UPDATE: in case I modified anything while trying to make it build in other ways (buildwin.cmd, Batch Build in Visual Studio), I set the entire Poco file structure aside, and unzipped a fresh copy. The OpenSSL install is also fresh and untouched. The x64 build produces the identical error...

There is a hidden readme file https://github.com/pocoproject/poco/blob/master/README. I'm quoting:
Through the Poco/Crypto/Crypto.h and Poco/Net/NetSSL.h header files,
Visual C++ will automatically link the libcrypto.lib and libssl.lib
libraries. If your OpenSSL libraries are named differently, compile
with the macro POCO_EXTERNAL_OPENSSL defined and edit the project
files accordingly.
You can try to re-compile with the POCO_EXTERNAL_OPENSSL macro set accordingly (see Foundation/include/Poco/Config.h). (source)
Or what I did. Edit the file Crypto/include/Poco/Crypto/Crypto.h, remove all if-else logic around pragmas and leave only libraries that use have:
#pragma comment(lib, "libcrypto64md.lib")
#pragma comment(lib, "libssl64md.lib")

This is not a direct answer - it is an alternative build path that has been confirmed to produce viable DLLs. Try:
Start command line tool from Visual Studio
Invoke vcvars32.bat or vcvars64.bat to ensure environment is correct for Win32 or x64 build.
I found these scripts in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build
Ensure the Poco buildwin.cmd script is configured to specify location of OpenSSL include and lib sub-folders
you will likely have to modify the script between builds if building both 32- and 64-bit builds since openSSL-Win32 and openSSL-Win64 are separate installations
specify include and lib paths for other components the same way (e.g. MySQL and/or PostgreSQL, etc)
Edit the Poco "components" file to eliminate any components not required that will stop build
Invoke buildwin, e.g.:
buildwin 160 shared both Win32 samples notests
buildwin 160 shared both x64 samples notests

Related

How to use MsBuild.exe to build a fortran/c mixed project?

1. Background
I have a project which is managed by cmake, I then generate the solution files by Visual Studio 2019 geneartor. The folder strucutre looks like:
- main.sln
- fotran_proj.vfproj (output a static lib libfortran.lib)
- C_proj.vcxproj (dependent on libfortran.lib)
- ALL_BUILD.vcxproj
It contains both fortran and c projects, and c project is dependent on fortran project.
I want to build the whole solution from commandline by msbuild.exe.
2. Environment
I use VS2019 with Intel Fortran Compiler on win10.
3. Question
When I try to use msbuild.exe to build it:
MSBuild.exe /t:build ALL_BUILD
It simply build the vcxproj part and ignore the vfproj parts. Why? How can I achieve this?
To the best of my knowledge, you can't do this. Intel Fortran's build system isn't recognized by msbuild, though that integration might happen sometime in the future.
What you can do is use devenv from the command line to build your mixed-language solution. From an Intel Fortran command prompt window (or one where you have established the Intel environment), type devenv /? to see the usage and options. For example, I built a mixed-language solution as follows:
devenv C_calls_F.sln /build "Debug|Win32"

Blender in CLion: MSVC_REDIST_DIR-NOTFOUND, LIBDIR cmake variable

I am trying to build the Blender project in CLion, and failing with just configuring the IDE.
First, but not so crucial IMO, I am not sure which Architecture should I select in the Settings. By default CLion decided to go with x86, but that sounds like 32bit Windows to me... in 2022?
(But as long as I can build the project I guess win32 should not bother me.)
This seems like a bigger problem:
CMake Warning at C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.21/Modules/InstallRequiredSystemLibraries.cmake:601 (message):
system runtime library file does not exist:
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.CRT/msvcp140.dll'
...
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.CRT/vcruntime140.dll'
...
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.CRT/concrt140.dll'
...
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.OPENMP/vcomp140.dll'
...
CMake Error at build_files/cmake/platform/platform_win32.cmake:264 (message):
32 bit compiler detected, blender no longer provides pre-build libraries
for 32 bit windows, please set the `LIBDIR cmake variable` to your own
library folder
All those "missing" files are scattered in the Visual Studio subdirectory "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC\14.30.30704\x86\Microsoft.VC143*" directories, but for some reason CMake "decided" to go with VC142.
1) How does one convince CMake to go with VC143?
2) How does one set the LIBDIR cmake variable?
I suppose this one could go away once the Nr.1 problem gets resolved, but if not... Where should the variable point to, and what would its full name be? Just LIBDIR? (I am seeing CMAKE_INSTALL_ and CMAKE_INSTALL_FULL_ prefixes mentioned in GNUInstallDirs.cmake.)
Anyways, I suspect it should be set here?
So apparently there's a bug in VS2022. This version comes with CRT143 (whatever it is) yet the bundled scripts identify the VS as 2019 which only knows/recognizes CRT up to version 142.
https://developercommunity.visualstudio.com/t/1616850

CMake with Build Tools for Visual Studio 2019 (Just the CLI not the IDE)

I am trying to build my code with Cmake and Visual Studio 2019 Build Tools.
Note that I'm not using the IDE only the Build Tools CLI.
When I try to generate my project like this:
cmake -G "Visual Studio 16 2019" -S . -B .
CMake returns this:
Generator
Visual Studio 16 2019
could not find specified instance of Visual Studio:
C:/Program Files (x86)/Microsoft Visual Studio/2019/Community
How can I make CMake to look for the Build Tools location and not for the IDE location?
I haven't used Visual Studio in years, but according to CMake's documentation on the Visual Studio 16 2019 generator, you can use a CMake variable or an environment variable to control which instance you use.
VS 2019 supports multiple installations on the same machine. The CMAKE_GENERATOR_INSTANCE variable may be set as a cache entry containing the absolute path to a Visual Studio instance. If the value is not specified explicitly by the user or a toolchain file, CMake queries the Visual Studio Installer to locate VS instances, chooses one, and sets the variable as a cache entry to hold the value persistently.
When CMake first chooses an instance, if the VS160COMNTOOLS environment variable is set and points to the Common7/Tools directory within one of the instances, that instance will be used. Otherwise, if more than one instance is installed we do not define which one is chosen by default.
Make sure you have all of the necessary individual components selected when installing the build tools.
Make sure CMake can find the tools (e.g. add the paths to your Path variable).
As a proof of concept for my case, I added the following to my user Path variable for lib.exe, cl.exe, link.exe, etc...:
C:/Program Files (x86)/Microsoft Visual Studio/2019/BuildTools/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64
And the following path for mt.exe and rc.exe:
C:/Program Files (x86)/Windows Kits/10/bin/10.0.18362.0/x64

Is it possible to build cmake projects directly using MSBuildTools

Currently we are planning to use VS2017 with a cmake project. Inside Visual Studio this works quite like a charm.
Now want to run our builds as part of CI on a dedicated build master running MSBuildTools.
Is it possible to directly run the build using the msbuild command, without creating solution files with cmake? Optimally, I would even use the CMakeSettings.json used from VS2017.
Use the build-tool-mode of CMake for this. It uses the underlying default build tool which is MSBuild for Visual Studio Generators.
From the build directory call:
cmake --build . --target ALL_BUILD --config Release -- /nologo /verbosity:minimal /maxcpucount
and you get a fast, nearly quiet build. To install use INSTALL target, for running your tests if configured use RUN_TESTS target.
Is it possible to directly run the build using the msbuild command, without creating solution files with cmake?
Is it possible to directly run the build using the msbuild command, without creating solution files with cmake?
As far as I know, CMake produces Visual Studio Projects and Solutions seamlessly. So you can produce projects/solutions.
The only tricky part is to remember to make any changes in the cmake files, rather than from within Visual Studio.
In particular, each CMake project will create a Visual Studio solution (.sln file), while all of the CMake targets belonging to that CMake project will appear as Visual Studio projects within the corresponding solution.
CMake Visual Studio
project <-> Solution (.sln)
Target <-> Project (.vcxproj)
You can check cmake-and-visual-studio for more details.
Since MSbuild can build both solution files and project files, so you could also call msbuild INSTALL.vcxproj
Is it possible to even use the CMakeSettings.json used in VS2017?
The answer is yes, check the blog for details.
If your CMake project requires additional settings to configure the
CMake cache correctly, you can customize these settings by creating a
CMakeSettings.json file in the same folder with the root
CMakeLists.txt. In this file you can specify as many CMake
configurations as you need – you will be able to switch between them
at any time.
You can create the CMakeSettings.json file by selecting the Project >
Edit Settings > path-to-CMakeLists (configuration-name) menu entry.

Compiling clang/LLVM on win results in compile errors - how to fix?

I've stumbled upon problems installing clang/LLVM on my Win 7 64-bit machine for setting up Emscripten in my Visual Studio 2010 Setup. I was following the official howto from Emscripten at https://github.com/kripken/emscripten/wiki/Using-Emscripten-on-Windows and stumbled into problems regarding the needed compilation of clang/LLVM.
svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_32/final llvm
cd llvm\tools
svn co http://llvm.org/svn/llvm-project/cfe/tags/RELEASE_32/final clang
cd ..\\..
mkdir build
cmake -G "Visual Studio 10" ..\llvm
msbuild LLVM.sln /p:Configuration=Release
The result is alot of errors similiar to this one:
CUSTOMBUILD : error : error reading '10.0\VC\bin\llvm\tools\clang\test\Index\
pch-opaque-value.cpp' [c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\b
in\build\tools\clang\test\check-clang.vcxproj]
CUSTOMBUILD : error : error reading '10.0\VC\bin\llvm\tools\clang\test\Index\
pch-with-errors.m' [c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\
build\tools\clang\test\check-clang.vcxproj]
Obviously, a path starting at
'10.0\VC...' is totally invalid.. its missing the 'C:\Program Files (x86)\Microsoft Visual Studio ' in front.. (I've checked there is a file like that in test\Index\ - it is!
My question is: how do I fix that ?
a) Can I setup an additional include path that is like 'C:\folder\MS Visual ' (including space) ?
What I have tried so far:
a) Doing it from Visual Studio Prompt and normal Prompt. Using default and custom location.
b) Running MSBUILD like
msbuild LLVM.sln /p:Configuration=Release /p:"VCBuildAdditionalOptions= C:\Program Files (x86)\Microsoft Visual Studio "
c) Trying to change PATH/Systemroot.. Destroyed my systemroot in the meantime for unknown reasons (It complaimed about a wrong path like "C:\Program " and erased it obviously).
I am seriously stuck and dont know any further than these steps. Setting up an include path does not seem to help - though I'm wondering if the CMAKE stuff had problems with space's or what is going on.
Since the authors of Emscripten and probably LLVM call their windows support "experimental", I'm not the only one having troubles trying to set up LLVM/clang for later use with Visual Studio 2010 (not 2012..). I'm sorry for the bad formatting, for some reason SO won't allow me neat formatting today.. I'm using a nightly browser build though.
If you just need a build of LLVM, you can generate NMake Makefiles and build with nmake instead of msbuild. It seems that there is a quoting issue somewhere (might be CMake, CmakeLists.txt, msbuild, who knows).
On second thought, this might be a problem with environment variables. How did you set up PATH? Try from a new "Visual Studio Developer Command Prompt".