Unable to build GDAL Visual Studio project with "generate_vcxproj.bat" - c++

I need to link GDAL library to a c++ project.
I use the instruction from here:
http://trac.osgeo.org/gdal/wiki/GeneratingVisualStudioProject
Download gdal231.zip from official web site. Unpack.
(this step may be omitted — result will be the same) Edit nmake.opt by adding this in the very top of the file:
MSVC_VER=1910
WIN64=1
(don't know if it's right; there is no thorough guide)
Run win cmd, type "generate_vcxproj.bat 15.0 64 gdal_vs2017", wait for finish.
Open gdal_vs2017.vcxproj with MSVS Community 15.8.4. Build solution.
Build failed with "fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory".
Project settings look strange:
1
"VC++ Directories" seem normal, except $(VC_SourcePath) in "Library Directories":
2
What's wrong with it?

In order to build GDAL one doesn't need a Visual Studio project. Don't know what's wrong with "generate_vcxproj" script — it just does'nt work. But there is another way.
Unpack gdal231.zip.
Launch "x64 Native Tools Command Prompt for VS 2017" (or whatever version of VS command prompt that suits your needs). cd to "gdal-2.3.1\" dir.
Open nmake.opt file. In it's beginning there are some hints for usage of makefile.vc. Pick some arguments from there. I opt for x64 release build, so my call to nmake was like that: "nmake -f makefile.vc MSVC_VER=1910 WIN64=1". (1910 is a version of Visual Studio 2017).
Switch to "Native tools command prompt" and type "nmake -f makefile.vc MSVC_VER=1910 WIN64=1" there. Enter.
When it's finished, type "nmake -f makefile.vc MSVC_VER=1910 WIN64=1 install" and press Enter.
When that's finished too, type "nmake -f makefile.vc MSVC_VER=1910 WIN64=1 devinstall" and press Enter.
Done. The library is in C:\warmerda\bld\ folder.

I got the same problem when building with VS2017 Community Edition. I was able to build fine using VS2015 Community Edition.
Bottom line: when running the .bat, use the 2015 option.

Modify the generate_vcxproj.bat file using the information from here:
https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering
I modified mine to work with Visual Studio Community 2019 by modifying lines 55-70 to be this:
if "%_vcver_%"=="16.2" (
set _clver_=1922
set _vstoolset_=v1422
) else if "%_vcver_%"=="15.0" (
set _clver_=1910
set _vstoolset_=v141
) else if "%_vcver_%"=="14.0" (
set _clver_=1900
set _vstoolset_=v140
) else ( if "%_vcver_%"=="12.0" (
set _clver_=1800
set _vstoolset_=v120
) else (
echo Wrong value for parameter 1. See usage:
goto :usage
))

Related

MysqlConnector C++ (including jdbc) building from source using CMake

I got the latest version of mysql connector/c++ source code form the github respiratory https://github.com/mysql/mysql-connector-cpp. In order to install it I followed the doc:
https://dev.mysql.com/doc/connector-cpp/8.0/en/connector-cpp-installation-source.html.
I did configuration and generate the mysql connector/c++ using CMake GUI ver. 3.22 In order to build and install the connector/c++ I used Visual Studio 2022 and Visual Studio 17 2022 compiler. During building I had two problems in two subprojects(in the solution tree) - namely in: connector and connector-jdbc:
Severity Code Description Project File Line Suppression State
Error MSB3073 The command "setlocal
"C:\Program Files\CMake\bin\cmake.exe" -DTARGET=P:/mysql-connector-cpp/_build/jdbc/Release/mysqlcppconn-static.lib -DTYPE=STATIC -DBUILD_LOG=P:/mysql-connector-cpp/_build/jdbc/Release/connector-jdbc.log.STATIC -DMSBUILD=ON -DMSVC=19.30.30709.0 -DINFO=P:/mysql-connector-cpp/_build/jdbc/INFO_BIN -DINFO_PREFIX=jdbc- -P P:/mysql-connector-cpp/_build/libutils/merge_archives.cmake
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
:VCEnd" exited with code 1. connector-jdbc C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets 156
I got rid of the the problem by going to properties of the connector and connector-jdbc subprojects next to Post-Build-Events and finally by removing that what was in the field of "Command Line".
I built and installed the connector/c++ you can access it on github: https://github.com/SPiernikowski/mysqlConnector
All variables used when configuring using cmake gui are in the CMakeCache.txt file.
According to doc in paragraph:"Installing Connector/C++ from Source"(https://dev.mysql.com/doc/connector-cpp/8.0/en/connector-cpp-installation-source-cpp.html)
"If the build is successful, it creates the connector libraries in the build directory. (For Windows, look for the libraries in a subdirectory with the same name as the build_type value specified for the --config option.)"
I wanted to get static libs for jdbc and xapi respectively on Windows so:
accor.to doc: "If you build legacy static libraries, they have these names:"
mysqlcppconn-static.lib (Windows) - this is for jdbc
mysqlcppconn8-static.lib (Windows) - this is for xapi
Hereunder conserns when solution is already built:
I can find these two files first for xapi in /Release/mysqlcppconn8-static.lib (see on github link to the respiratory is the third one)
and the second one for jdbc in /jdbc/Release/mysqlcppconn-static.lib (see on github link to the respiratory is the third one)
The problem is that each libs file volume are only 2kB.
Definetly something went wrong but I am not able to find the reason.
I opend the mysqlcppconn-static.lib file:
hereunder see the part of it:
/DEFAULTLIB:"MSVCRT" /DEFAULTLIB:"OLDNAMES" ń Ś N P:\mysql-connector-cpp_build\jdbc\connector-jdbc.dir\Release\empty.obj :
Despite this I can find libs for every subprojects:
/xapi/Release/xapi.lib - volume 6097kB
/jdbc/driver/Release/jdbc.lib - volume 4413kB
/devapi/Release/devapi.lib - volume 6073 ... and so on
Hereunder conserns when solution is already installed:
I can find in /_install/lib64/vs14 folder the two libs:
mysqlcppconn8-static.lib and mysqlcppconn-static.lib but thay have only
2KB volume each (see it in repo on git in the _install folder)
Maybe I wrongly configured something in CMake???
I add that mysqlcppconn-static.lib volume should be 55628kB
Maybe the problem is trivial but I can not see it. Please share with me if you see something is done wrongly.

Trying to build GDAL from github using Visual Studio 2019 v16.6.5 on Windows 10 x64

I want to use Visual Studio 2019 to build GDAL. But I keep getting errors when trying to build.
The computer I'm using is Acer Aspire f 15 F5573G-72CP,
CPU is i7 7500U 2.7GHz, RAM is 16GB, OS is Windows 10 64 bit
Steps I've taken are:
Download Visual Studio Community, included .NET desktop development, Universal Windows Platform development, Desktop development with C++ and Node.js development.
Used GIT BASH from git for windows to pull the repo https://github.com/OSGeo/GDAL.git and located it c:/gdal
in c:/gdal/GDAL/nmake.opt:
3.a. changed line 42 to Line 42: MSVC_VER=1926
3.b. I uncommented line 260:
Line 259: # PROJ stuff (required dependency: PROJ >= 6)
Line 260: PROJ_INCLUDE = -Id:\install-proj\local\include
3.c. Uncommented line 213: Line 213: WIN64=YES
Also pulled the repo: https://github.com/OSGeo/PROJ.git located at c:/proj/PROJ
Using Windows Powershell, cd c:/gdal/gdal -> generate_vcxproj.bat 16.0 64 gdal_vs2019
which outputs the following:
PS C:\gdal\gdal> .\generate_vcxproj.bat 16.0 64 gdal_vs2019
The system cannot find the path specified.
Generating:
"C:\gdal\gdal\gdal_vs2019.vcxproj"
"C:\gdal\gdal\gdal_vs2019.vcxproj.user"
"C:\gdal\gdal\gdal_vs2019.vcxproj.filters"
"C:\gdal\autotest\cpp\gdal_vs2019_test.vcxproj"
"C:\gdal\autotest\cpp\gdal_vs2019_test.vcxproj.user"
"C:\gdal\autotest\cpp\gdal_vs2019_test.vcxproj.filters"
This might take a little while...
Projects done!
Launch Visual Studio IDE
* Open project "C:\gdal\gdal\gdal_vs2019.vcxproj"
* Add project "C:\gdal\autotest\cpp\gdal_vs2019_test.vcxproj"
* Configure Build Dependencies to build the main project before the test project.
* Save solution in .sln file
Done!
PS C:\gdal\gdal>
Open Visual Studio 2019, open a project or solution, select C:\gdal\gdal\gdal_vs2019.vcxproj, ensure Solution Platforms dropdown is set to x64, Build->Build Solution, which returns three errors:
Severity Code Description Project File Line Suppression State
Error U1077 'call' : return code '0x1' gdal_vs2019 C:\gdal\gdal\NMAKE 1
Severity Code Description Project File Line Suppression State
Error U1077 '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x64\nmake.EXE"' : return code '0x2' gdal_vs2019 C:\gdal\gdal\NMAKE 1
Severity Code Description Project File Line Suppression State
Error MSB3073 The command "chcp 65001 >NUL && nmake -f makefile.vc MSVC_VER=1926 WIN64=1 DEBUG=1 WITH_PDB=1" exited with code 2. gdal_vs2019 C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.MakeFile.Targets 46
The Output tab shows:
1>------ Build started: Project: gdal_vs2019, Configuration: Debug x64 ------
1>
1>Microsoft (R) Program Maintenance Utility Version 14.26.28806.0
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>
1> cd port
1> nmake /nologo /f makefile.vc
1> call prev_dllbuild.bat
1>The system cannot find the path specified.
1>
1>C:\gdal\gdal\port>IF NOT EXIST dllbuild.prev (ECHO 1 ) 1>dllbuild.prev
1>
1>C:\gdal\gdal\port>SET /P PREV_DLLBUILD= 0<dllbuild.prev
1>
1>C:\gdal\gdal\port>IF NOT "1" == "1" (ECHO 1 ) 1>dllbuild.prev
1>NMAKE : fatal error U1077: 'call' : return code '0x1'
1>Stop.
1>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x64\nmake.EXE"' : return code '0x2'
1>Stop.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.MakeFile.Targets(46,5): error MSB3073: The command "chcp 65001 >NUL && nmake -f makefile.vc MSVC_VER=1926 WIN64=1 DEBUG=1 WITH_PDB=1" exited with code 2.
1>Done building project "gdal_vs2019.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
How should I address these errors to get GDAL built successfully?
This is a little late, but have you tried the following:
Read https://trac.osgeo.org/gdal/wiki/BuildingOnWindows
Read https://trac.osgeo.org/gdal/wiki/BuildHints for specific
needs/dependencies/drivers
Get all the dependencies you need
Edit nmake.opt to disable/enable features/drivers you don't
need
Run NMAKE
You could also try cleaning:
nmake /f makefile.vc clean
nmake /f makefile.vc
Finally, you could try building on a different computer.
Hark, this is the way one should ask questions: clear, precise steps, detailed description. Very helpful!
I could compile when I didn't use the GIT repo. Instead I downloaded PROJ following their Windows installation documentation:
The simplest way to install PROJ on Windows is to use the OSGeo4W_
software distribution. OSGeo4W provides easy access to many popular
open source geospatial software packages. After installation you can
use PROJ from the OSGeo4W shell. To install PROJ do the following:
note::
If you have already installed software via OSGeo4W on your computer, or if
you have already installed QGIS on your computer, it is likely that PROJ is
already installed. Type "OSGeo4W Shell" in your start menu and check whether
that gives a match.
Download either the 32 bit or 64 bit installer.
Run the OSGeo4W setup program.
Select "Advanced Install" and press Next.
Select "Install from Internet" and press Next.
Select a installation directory. The default suggestion is fine in most cases. Press Next.
Select "Local package directory". The default suggestion is fine in most cases. Press Next.
Select "Direct connection" and press Next.
Choose the download.osgeo.org server and press Next.
Find "proj" under "Commandline_Utilities" and click the package in the "New" column until the version you want to install appears.
Press next to install PROJ.
I downloaded the installers from osgeo4W. Because I needed both 32 and 64 bit versions I downloaded osgeo4w-setup-x86-v1.exe and osgeo4w-setup-x86_64-v1.exe. The download got stuck after 25% when downloading the big proj-file from osgeo, so I selected the oslandia download link instead. This initially fails (at least for me), but after restart it could finish.
In the download package selection click on the "Skip" logo to select binary ("B") and source ("S"). I selected both. I downloaded "proj", "proj-dev" and "proj-dev-data", not sure what is actually neeeded. When it asked to include dependencies (a lot), I selected to include them.
In the nmake.opt (your step 3) I used for the 32 bit:
PROJ_INCLUDE = -IC:\OSGeo4W\include
PROJ_LIBRARY = C:\OSGeo4W\lib\proj.lib
and for the 64 bit:
PROJ_INCLUDE = -IC:\OSGeo4W64\include
PROJ_LIBRARY = C:\OSGeo4W64\lib\proj.lib
For running the generate_vcxproj.bat, I used Visual Studio 2022 x86 and x64 native tool command prompts. In the bat-file I changed:
if "%_vcver_%"=="16.0" (
set _clver_=1926
set _vstoolset_=v143
And in the nmake.opt:
MSVC_VER=1929
I run the bat separately for 64 and 32 bits:
generate_vcxproj.bat 16.0 64 gdal_vs2022
generate_vcxproj.bat 16.0 32 gdal_vs2022_x86
After this step I could open the vcxproj-files in Visual Studio and compile the libraries. I used the genererated gdal_i.lib's and accompanying gdal303.dll's in my project.

Can build Mysql Connector C++ on vs 2017?

I tried to build mysql-connector-c++ from source to static library.
Referring the official spec here, I generated the Visual studio solution by the following command:
cmake -DMYSQL_DIR="E:\mysql-5.7.21-winx64" -DWITH_BOOST="E:\libs\boost_1_67_0_BUILDED" -DWITH_JDBC=ON -G "Visual Studio 15 2017 Win64" ../
Then, I opened the vs solution generated by cmake.Run build, got the two libs: mysqlcppconn8-static-mt.lib, mysqlcppconn-static-mt.lib, and copied them to my project.
When I built my project (also vs2017 version), I got the error:
mysqlcppconn-static-mt.lib(net_serv.obj) : error LNK2038: 检测到“_MSC_VER”的不匹配项: 值“1800”不匹配值“1900”(ActionProcessor.obj 中)
I am confused. They're all built in vs2017, and platform toolset are all set to "Visual Studio 2017 (v141)". I can't understand where 1800_MSC_VER has come from.
Here is what I did
Specs
Visual Studio 15, (2017)
x64
Static (.lib)
With static runtime (/MT)
Tools
CMAKE
Bison (In a folder without spaces)
Perl (ActiveState or Strawberry)
OpenSSL 1.0.2q.tar.gz
Add CMAKE, Bison and pearl to your system path
Check to see if you got all setup correctly
C:\>cmake --version
cmake version 3.9.6
C:\>bison --version
bison (GNU Bison) 2.4.1
C:\>m4 --version
m4 (GNU M4) 1.4.13
C:\>perl -version
This is perl 5, version 24, subversion 3 (v5.24.3)
Step 1: Build OpenSSL 1.0.x
Note: if you want to build OpenSSL 1.1.x steps will be a bit different
Extract to: C:\mysql-8.0.15\openssl-1.0.2q
Run: x64 Native Tools Command prompt for VS 2017
cd C:\mysql-8.0.15\openssl-1.0.2q
Release
perl Configure VC-WIN64A no-shared --openssldir=.\rel64
ms\do_win64a
nmake -f ms\nt.mak
nmake -f ms\nt.mak install
Debug
nmake -f ms\nt.mak clean
perl Configure debug-VC-WIN64A no-shared --openssldir=.\dbg64
ms\do_win64a
nmake -f ms\nt.mak
nmake -f ms\nt.mak install
Step 2: Build MySQL (Yes the actual database)
Extract to: C:\mysql-8.0.15
Run: x64 Native Tools Command prompt for VS 2017
cd C:\mysql-8.0.15\
cmake . -G "Visual Studio 15 2017 Win64" ^
-DWITH_BOOST=C:/mysql-8.0.15/boost ^
-DDOWNLOAD_BOOST=1 ^
-DBUILD_CONFIG=mysql_release ^
-DWITH_SSL=C:\mysql-8.0.15\openssl-1.0.2q\rel64 ^
-DLINK_STATIC_RUNTIME_LIBRARIES=1
Copy m4.exe to C:\mysql-8.0.15\sql\ this avoids any m4.exe errors during built
Open MySQL.sln and build for release x64
Copy binary_log_funcs.h and binary_log_types.h from mysql-8.0.15\libbinlogevents\export to mysql-8.0.15\include
The library should be located at:
Static release library: C:\mysql-8.0.15\archive_output_directory\Release\mysqlclient.lib
Step 3: Build MySQL Connector C++
Copy C:\mysql-8.0.15-dbg\archive_output_directory\Debug\mysqlclient.lib
to C:\mysql-8.0.15-dbg\lib\vs14
Run CMAKE GUI
Browse to the path of the MySQL Connector Project.
Click Configure, Select Visual studio 15 2017 Win64, native compilers
Tick BUILD_STATIC
Tick STATIC_MSVCRT
TICK WITH_JDBC
remove WIN_SSL_YASL from CONFIG_VARS
WITH_SSL = C:\mysql-8.0.15\openssl-1.0.2q\rel64
WITH_BOOST= C:\mysql-8.0.15\boost\boost_1_66_0
MYSQL_DIR=C:\mysql-8.0.15
Open MySQL_CONCPP.sln build for Release x64
The library is located at:
C:\mysql-connector-c++-8.0.15\jdbc\install\lib\mysqlcppconn-static-mt.lib
C:\mysql-connector-c++-8.0.15\Release\mysqlcppconn8-static-mt.lib
Step 4: Test it
Note: This test is for the JDBC style API. If you are not maintaining an existing application, use the new xdevapi API.
Create a new project and put the following in main.cpp
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#define STATIC_CONCPP
#define CONCPP_BUILD_STATIC
#define CPPCONN_PUBLIC_FUNC
#include <driver.h>
#include <connection.h>
#include <statement.h>
#include <exception.h>
sql::Driver *mDriver;
sql::Connection *mConnection;
int main() {
mDriver = get_driver_instance(); //or use: new MySQL_Driver()
try {
mConnection = mDriver->connect("host", "username", "password");
mConnection->close();
}catch(sql::SQLException& ex) {
std::cout << ex.what();
}
delete mConnection;
return 0;
}
Set: Linker > Input > Additional Dependecies:
libeay32.lib;mysqlclient.lib;mysqlcppconn8-static-mt.lib;mysqlcppconn-static-mt.lib;ssleay32.lib;%(AdditionalDependencies)
Set: Configuration Properties > VC++ Directories
Include Directories.
Library Directories.
I don't even know where to start explaining to be honest. Building this was a massive pain.
Before you begin to read this, please ensure you have the following:
C:\boost
C:\OpenSSL-Win32
C:\OpenSSL-Win64
Because I was writing my own "wrapper" and trying to make UNICODE work properly, I was getting weird exceptions, and I was unable to debug anything because I downloaded the latest package which is built without debug information (https://dev.mysql.com/downloads/connector/cpp/)
This is the first time I try to build this, so I went to their Github repository and grabbed the latest "master": https://github.com/mysql/mysql-connector-cpp
BUT! This does not contain the "JDBC" sources, which is by the way the "native" connector as they call it. So I grabbed it from the branch: https://github.com/mysql/mysql-connector-cpp/tree/jdbc and then copied the files into "mysql-connector-cpp-master\jdbc".
OK. I opened "x64 Native Tools Command Prompt for VS 2017" and navigated to "mysql-connector-cpp-master". At this point I still had no idea what I am doing and how to build it, all I could understand from the docs and different articles here is to run:
cmake -DWITH_JDBC=ON --build .
This started to configure things and build OK, but it stopped here:
-- Searching for static libraries with the base name(s) "mysqlclient"
CMake Error at FindMySQL.cmake:524 (message):
Could not find "mysql.h" from searching "/usr/include/mysql
/usr/local/include/mysql /opt/mysql/mysql/include
/opt/mysql/mysql/include/mysql /usr/local/mysql/include
/usr/local/mysql/include/mysql C:\Program Files/MySQL/*/include
C:/MySQL/*/include"
Call Stack (most recent call first):
CMakeLists.txt:332 (INCLUDE)
OK. So what now... where is "mysql.h" ?! After searching... and searching, I found this: Missing mysql.h and trying to find mysql-devel
And I quote:
Grab the MySQL Community Server and install it on your system. It
contains a directory called include in which you find the mysql.h.
Ok, great we need more stuff. So I download: https://dev.mysql.com/downloads/mysql/ and run the command again.
Happy days, something happened but no libs yet. I did get however a VS 2017 solution called: "MYSQLCPPCONN.sln".
This contains VS 2017 configuration to build the library for Win32. And of course trying to build with this solution will give you A LOT of unresolved external symbols.
So I run again the cmake but with static option added:
cmake -DWITH_JDBC=ON -DBUILD_STATIC=ON --build .
This time when I open "MYSQLCPPCONN.sln" I can see another project "mysqlcppconn-static" and this builds fine without issues.
However, in my case I need x64. I just created a new configuration for x64 by copying the exiting configuration fron Win32.
So that's it, I have both Win32 and x64 "mysqlcppconn-static.lib".
Overall Conclusion at this time:
Quite hard to build, without experience you will spend some time...
time.
No proper documentation, their existing documentation is poorly
written and very confusing.
No UNICODE support, yes the projects compile as Multi-Byte
Character Set.
I will see if I can debug and find out why am I getting exceptions in the library when using this (from their documentation):
sql::ConnectOptionsMap connection_properties;
connection_properties["hostName"] = "";
connection_properties["port"] = "";
connection_properties["userName"] = "";
connection_properties["password"] = "";
connection_properties["schema"] = "";
connection_properties["OPT_CONNECT_TIMEOUT"] = 10;
connection_properties["CLIENT_MULTI_STATEMENTS"] = (true);
connection_properties["OPT_CHARSET_NAME"] = "utf8";
connection_properties["OPT_SET_CHARSET_NAME"] = "utf8";
I hope you can build your library with this information, and hopefully in the future it will become more easier and clear.
Good Luck.

Visual Studio: MSB3073 error exited with code 1

everyone. I am compiling DCMTK 3.6.1 in Visual Studio 2013. My OS is Windows 8. I also used CMake 3.2.3. I have already successfully compiled both x64 versions of debug and release for the ALL_BUILD project. However, for the INSTALL project, I can't compile it because the following error occurs:
Error 1 error MSB3073: The command "setlocal
"C:\Program Files (x86)\CMake\bin\cmake.exe" -DBUILD_TYPE=Release -P cmake_install.cmake
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
:VCEnd" exited with code 1. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets 132
According to this link, I need admin rights. But I am already running Visual Studio in Admin mode. Can someone please enlighten me on what I might be doing wrong? Thank you very much!
What about specifying another value for CMAKE_INSTALL_PREFIX in the CMake GUI? That means, a directory where you definitely have write access.
This is an old post, but I encountered the same problem when I attempted to install OpenCV for Windows 10 using VS 16 2019 in a folder close to the root of C:.
Solution: Open cmd as administrator, open the SLN-project (In my case <OpenCV.sln>), and run Build on INSTALL. That worked like a charm.
This is a simple 2 step fix.
First step is to remove the Read Only folder property. To do this, just go wherever you cloned the software you want to build, right click on the containing folder and uncheck the Read Only checkmark.
Second step is to exit visual studio and start terminal as administrator/with sudo privileges if on linux/mac. Navigate to the build folder and type the solution name. This will open up VC with admin privileges.
This fixed the problem for me.
Just open a prompt and run "C:\Program Files (x86)\CMake\bin\cmake.exe" -DBUILD_TYPE=Release -P cmake_install.cmake (or similar showed in VS error list) and see where is the problem
in my case the problem was samples were not compiled, so i entered in modules directory and compile manually each module necessary.
After compile the module i run the command again and see what happen, repeat until solve the problem
the best solution;
CMAKE_INSTALL_PREFIX
if you choose realease/debug then after CMake configure by CMake on the same mood.
just try
I had a similar error, if you can check that there are no spaces or character symbols in your path. FOr example I had a directory with the file name 'ABC&D' and by removing & the error was fixed.
This coupled with allowing admin rights should be an attempt to fix the problem.

OpenSSL build odd behaviour

Its kinda an odd story. I'm trying to build the openssl library. Well, it is not the first time I'm doing it and until now it was fine. however, I've desided to add a build configuration to TeamCity (actually the problem has nothing to do with TeamCity)to build all my third parties libraries on-demand. So, I created a step with common set of openssl build commands:
perl Configure VC-WIN64A
ms\do_win64a.bat
nmake /d /f ms\ntdll.mak
... and the build failed while assembling the very first asm file. So I ran same commands in VS2012 x64 command prompt and the build succedeed, as expected. It took a while untill I figured out that the problem is in output redirection. Teamcity redirects output from build step to the teamcity build log, so did I by adding ">1.txt" to "nmake /d /f ms\ntdll.mak" command, and the build failed. I would say it is somewhat unexpected reason for build to fail.
So far, I've tried:
Building the same from VS2010 command prompt with redirection,
failed.
Building the same from VS2010 command prompt without
redirection, succeded.
Building the same from VS2010/VS2012 command
prompt with redirection to file and forcing redirection to CON (nmake
/d /f ms\ntdll.mak >CON >1.txt) failed.
Googling for "nmake problems
when console output is redirected" - nothing
Googling for "openssl
build problems when console output is redirected" - nothing
My setup
- Win2008R2, virtual machine.
- VS2010, latest updates
- VS2012, Update 1
Actual error:
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\amd64\ml64.EXE"' : return code '0x1'
ml64.exe complains about the asm file stating it should end with "END" statement. It does, but...
Any ideas?
Ok, since the problem is in perl and writing files to stdout and then redirecting it you have to change following files to build x64 version:
crypto\aes\asm\aes-x86_64.pl
crypto\bn\asm\modexp512-x86_64.pl
crypto\bn\asm\x86_64-gf2m.pl
crypto\bn\asm\x86_64-mont.pl
crypto\bn\asm\x86_64-mont5.pl
crypto\md5\asm\md5-x86_64.pl
crypto\modes\asm\ghash-x86_64.pl
crypto\rc4\asm\rc4-md5-x86_64.pl
crypto\rc4\asm\rc4-x86_64.pl
crypto\sha\asm\sha1-x86_64.pl
crypto\sha\asm\sha512-x86_64.pl
crypto\whrlpool\asm\wp-x86_64.pl
crypto\x86_64cpuid.pl
engines\asm\e_padlock-x86_64.pl
you have to open these files and change all "open STDOUT "whateverfile"" to something like "open my $asmfile "whaeverfile"", then take care of string concatenation (only in x86_64cpuid.pl) and then print it to the file instead of STDOUT, something like "print $code" to "print $asm $code"
and of course, dont forget to close the file, in another words change the "close STDOUT" to "close $asmfile"
Obviously when building target other than x64 one will have to change another set of files.
Will try to communicate it to openssl maintainer.