difficulties with "cl.exe" (command line compiler from VisualStudio) and header files! - visual-c++

I have installed Microsoft Visual C++ Express Edition, Version 9.0.30729.1 SP.
The command line compiler that comes with it is at Version 15.00.30729.01 for 80x86.
I have installed OpenCV 20.0a.
I want to compile the following program:
#include <cv.h>
#include <cxcore.h>
#include <highgui.h>
int _tmain(int argc, _TCHAR* argv[])
{
IplImage *img = cvLoadImage("funny-pictures-cat-goes-pew.jpg");
cvNamedWindow("Image:",1);
cvShowImage("Image:",img);
cvWaitKey();
cvDestroyWindow("Image:");
cvReleaseImage(&img);
return 0;
}
The thing is, I do NOT want to use the "visual" aspect of Visual C++, I want to use the command line compiler which is "cl.exe".
When I try to compile this program, I get the error:
C:\visualcpp>cl OpenCV_Helloworld.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved.
OpenCV_Helloworld.cpp
OpenCV_Helloworld.cpp(6) : fatal error C1083: Cannot open include file: 'cv.h': No such file or directory
So I tried to specifiy with /I like this
C:\visualcpp>cl /I "C:\OpenCV2.0\src\cv" OpenCV_Helloworld.cpp
And variations thereof, in the hope that /I would somehow tell cl.exe where cv.h is, but I get the same error.
As a side note, I don't know if that's related but I noticed that there is no file "cv.h" in "C:\OpenCV2.0\src\", but rather a file called "_cv.h"! So I changed the header accordingly, but still.
I think I'm able to program in C++ somewhat but I don't understand how to specify header / linker file locations, especially with cl.exe as I have only used gcc before and I don't think I know what I'm doing right now. Please help me to compile this! I want to get started in OpenCV.

First of all, be sure to set up the environment by calling one of the batch files that come with Visual Studio, i.e. vsvars32.bat found in your Visual Studio folder under Common7\Tools. During installation, there is usually also a start menu entry created which opens a console and executes the setup script. This will make sure environment variables are set up properly and the compiler and linker has access to header files, libraries, tools are on your path etc.
You will find the cl command line options listed here for documentation: Compiler Command-Line Syntax
As for OpenCV: Take a look at the directory structure of OpenCV. It's
OpenCVRootFolder\include\opencv\cv.h
so you would usually go ahead and say:
cl /I"X:\OpenCVRootFolder\include" [...] source.cpp /LINK [...]
and in your code, include the cv header via:
#include <opencv\cv.h>
...or you could just go ahead and do
cl /I"X:\OpenCVRootFolder\include\opencv" [...] source.cpp /LINK [...]
and simple include
#include <cv.h>
I don't see why you wouldn't want to use Visual Studio, though. It's just an IDE, there are no features forced upon you or included if you don't want them to.

There is no visual aspect of Visual Studio. It's just a name. All C++ programs are compiled with cl.exe. The C++ compiler has no knowledge of any visual anything - it's just a brand. cl.exe can only be invoked from within Visual Studio, however. It is not a command line compiler.

Related

Error Compiling C++/Cuda extension with Pytorch Cuda c++ in MSVC using CMake

I am trying to build a c++/cuda extension with Pytorch following the tutorial here, (with instructions how to use pytorch with c++ here). My environment details are:
Using Microsoft Visual Studio 2019 version 16.6.5
Windows 10
libtorch c++ debug 1.70 with cuda 11.0 installed from the pytorch website
I am using this cmake code where I set the include directory for python 3.6 and the library for python36.lib
cmake_minimum_required (VERSION 3.8)
project ("DAConvolution")
find_package(Torch REQUIRED)
# Add source to this project's executable.
add_executable (DAConvolution "DAConvolution.cpp" "DAConvolution.h")
include_directories("C:/Users/James/Anaconda3/envs/masters/include")
target_link_libraries(DAConvolution "${TORCH_LIBRARIES}" "C:/Users/James/Anaconda3/envs/masters/libs/python36.lib")
if (MSVC)
file(GLOB TORCH_DLLS "${TORCH_INSTALL_PREFIX}/lib/*.dll")
add_custom_command(TARGET DAConvolution
POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${TORCH_DLLS}
$<TARGET_FILE_DIR:DAConvolution>)
endif (MSVC)
I set the CMake command arguments to be -DCMAKE_PREFIX_PATH=C:\libtorch (my path to libtorch debug mentioned above). I am building with the x64-debug option in MSVC version (as building with the x-64 Release option gives me a torch-NOTFOUND error).
The example DAConvolution.cpp file is:
#ifdef _DEBUG
#undef _DEBUG
#include <python.h>
#define _DEBUG
#else
#include <python.h>
#endif
#include <torch/extension.h>
Where I have undefined the _DEBUG flag so that the linker does not look for the python36_d.lib file (which I do not have).
I am getting a linking error:
Simply including torch.h works fine, but when I want to include the extension header thats when I get these problems, as it uses Pybind 11 I believe. Any insights much appreciated. I have tried to include all the info I can, but would be happy to give more information.
For Windows and with Visual studio, you are better to work with the Visual Studio rather than the CMake.
Just create a simple Console Application, go to the project's Properties, change the Configuration type to Dynamic Library (dll), Configure the include and Library directories, add the required enteries to your linker in Linker>Input (such as torch.lib, torch_cpu.lib, etc) and you are good to go click build, and if you have done everything correctly you'll get yourself a dll that you can use (e.g loading it using torch.classes.load_library from Python and use it.
The Python debug version is not shipped with Anaconda/ normal python distribution, but if you install the Microsoft Python distribution which I believe can be downloaded/installed from Visual Studio installer, its available.
Also starting from Python 3.8 I guess the debug binaries are also shipped.
In case they are not, see this.
For the cmake part you can follow something like the following. This is a butchered version taken from my own cmake that I made for my python extension some time ago.
Read it and change it based on your own requirements it should be straight forward :
# NOTE:‌
# TORCH_LIB_DIRS needs to be set. When calling cmake you can specify them like this:
# cmake -DCMAKE_PREFIX_PATH="somewhere/libtorch/share/cmake" -DTORCH_LIB_DIRS="/somewhere/lib" ..
cmake_minimum_required(VERSION 3.1 FATAL_ERROR)
project(DAConvolution)
find_package(Torch REQUIRED)
# we are using the C++17, if you are not change this or remove it altogether
set(CMAKE_CXX_STANDARD 17)
#define where your headers and libs are, specify for example where your DaConvolution.h resides!
include_directories( somewhere/Yourinclude_dir ${TORCH_INCLUDE_DIRS})
set(DAConvolution_SRC ./DAConvolution.cpp )
LINK_DIRECTORIES(${TORCH_LIB_DIRS})
add_library(
DAConvolution
SHARED
${DAConvolution_SRC}
)
# if you use some custom libs, you previously built, specify its location here
# target_link_directories(DAConvolution PRIVATE somewhere/your_previously_built_stuff/libs)
target_link_libraries(DAConvolution ${TORCH_LIB_DIRS}/libc10.so)
target_link_libraries(DAConvolution ${TORCH_LIB_DIRS}/libtorch_cpu.so)
install(TARGETS DAConvolution LIBRARY DESTINATION lib )
Side note:
I made the cmake for Linux only, so under Windows, I always use Visual Studio (2019 to be exact), in the same way I explained earlier. its by far the best /easiest approach imho. Suit yourself and choose either of them that best fits your problem.

Trying to find gsl library, the only thing I can find is a loop in the system

I am working currently a little bit with wind data and I am using GSL and PlPlot to visualize and work with it.
When I try to add GSL or PlPlot libraries:
#include <gsl/gsl_errno.h>
#include <gsl/gsl_spline.h>
I get this message:
inter.c:4:27: fatal error: gsl/gsl_errno.h: No such file or directory
#include <gsl/gsl_errno.h>
^
Far as I know, this means that I need to add the complete path to my library file, when I search for gsl then I get this:
find: File system loop detected; ‘/.snapshots/1/snapshot’ is part of the same file system loop as ‘/’.
/.snapshots/2/snapshot/usr/share/doc/packages/gsl
/.snapshots/93/snapshot/usr/share/doc/packages/gsl
/.snapshots/94/snapshot/usr/share/doc/packages/gsl
I have read a little bit (still searching on the web), something went wrong with the installation of gsl? and plplot?. Strange as it appears is the same with math.h. There is a main difference here, because math.h is detected but gsl/plplot are not. How can I find my path to the library files and how can I eliminate that recursion?.
By the way, gsl and math were installed by default on SuSE at the begining and plplot was installed after using yast. Also I can find the GSL and PlPlot directories but the files are missing.
Thanks for any help guys.

Why does ARM's cl.exe try to build x86 or x64 app from ARM Developer Command Line?

I'm working on a basic makefile file to test compiling our sources for alternate Microsoft environments, like Windows Phone. I opened an VS2012 ARM Developer Command Prompt and ran nmake on the makefile. It resulted in:
nmake /f makefile.namke
...
cl /c cryptlib.cpp cpu.cpp...
cryptlib.cpp
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\crtdefs.h(338):
fatal error C1189: #error: Compiling Desktop applications for the ARM platform is not supported.
cpu.cpp
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\crtdefs.h(338):
fatal error C1189: #error: Compiling Desktop applications for the ARM platform is not supported.
...
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
\VC\BIN\x86_ARM\cl.EXE"' : return code '0x2'
Stop.
"Desktop applications" is kind of ambiguous, so I searched Microsoft for the meaning of the term. It appears that means the toolchain is building x86 or x64 Metro UI-based application.
I feel like I'm suffering a disconnect, or Microsoft is suffering a disconnect and their tools are buggy.
Why is Microsoft's ARM version of cl.exe trying to build an x86 or x64 application instead of compiling for ARM? Or why is the VS2012 ARM Developer Command Prompt setting up for a x86 or x64 application?
I also tried remediating the problem, but the proposed solutions are not working. So now I am trying to understand what's going on at the highest levels.
For example, one answer says to add <WindowsSDKDesktopARMSupport>true</WindowsSDKDesktopARMSupport> to an ARM property sheet, but that did not work. Another answer says to add CXXFLAGS = /D _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE, but that did not work either.
The makefile is about as simple as it gets to test the compile under Microsoft's ARM toolchain.
LIB_SRCS = cryptlib.cpp cpu.cpp ...
LIB_OBJS = cryptlib.obj cpu.obj ...
TEST_SRCS = test.cpp bench1.cpp bench2.cpp ...
TEST_OBJS = test.obj bench1.obj bench2.obj ...
CXX = cl.exe /nologo
AR = lib.exe
CXXFLAGS =
all: cryptest.exe
cryptest.exe: $(TEST_OBJS) cryplib.lib
$(CXX) $(CXXFLAGS) /ref:cryplib.lib /out:$# $(TEST_SRCS)
cryplib.lib : $(LIB_OBJS)
$(CXX) $(CXXFLAGS) $(LIB_SRCS)
$(AR) $(LIB_OBJS)
The correct solution would be to add something similar to /D WINAPI_FAMILY=WINAPI_FAMILY_APP or /D WINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP.
The Windows SDK headers have three different API subset targets, "desktop", "app" (the new "metro" style app introduced in windows 8) and "phone". When building from within Visual Studio, the right subset is chosen automatically depending on the project type, but when building manually by invoking cl.exe, you need to manually specify the target. (The chosen target limits what declarations are visible in the headers, hiding the ones that are unavailable in the more limited ones.)
Out of tradition, desktop is the default, but when targeting ARM, you need to choose one of the other ones, since there's no publicly supported target for third party code in desktop mode for ARM. (The WinRT tablets did have a desktop mode, but third parties weren't allowed to build apps for it.)
Since Windows 10 and MSVC 2015, you don't need to distinguish between phone and app, but should use "app" for both.
The other flag that was suggested, _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE, basically tells the headers to pretend like you are allowed to build for the desktop API family even for ARM. To use it, it seems like you should define it like this: /D _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 (i.e. just defining it isn't enough, you should define it to 1). For plain code that doesn't use much of the windows API, this should also work equally well, but the better solution is to declare the real API target, to get proper warnings when trying to use APIs that aren't available.

How does Auto-Linking libraries in C++ work?

I am trying to auto-link following libraries. I've never used auto-linking feature and not sure how it works exactly. From my research this should work. When I include the dll to the project besides the SDL libraries I get following errors:
https://i.gyazo.com/e49a636ddad428fa48acdee78c930293.png
What are the steps to get Auto-linking working. Don't I need to specify some kind of path for this? Does it have to be in specific order?
This code is inside the DLL:
#include <SDL.h>
#include <SDL_image.h>
#include <SDL_mixer.h>
#include <SDL_ttf.h>
#pragma comment(lib, "SDL2.lib")
#pragma comment(lib, "SDL2main.lib")
#pragma comment(lib, "SDL2_image.lib")
#pragma comment(lib, "SDL2_mixer.lib")
#pragma comment(lib, "SDL2_ttf.lib")
Thank you for taking your time to answer.
You haven't explicitly specified what platform or development environment you're using, but it looks like you're using a recent version of Visual Studio. You need to configure the "VC++ Directories" settings in your project to include the paths for the lib files, under "Library Directories". These pragma directives will instruct the linker to search for the lib files in these directories.
The compiler complains that it can't find the header sdl.h, it hasn't gotten to the linking part (and I'm guessing it would have trouble there too).
To solve:
Add the path to the SDL headers here: project properties\ C/C++ \ General \Additional include directories
Add the path to your import libs here: project properties \ Linker \ General \ Additional Library directories.
Don't fiddle with 'VC++ directories' - as the name suggests, it is where the toolchain seeks various VC components (crt, mfc, open mp, windows sdk etc.). Messing this up could result in extremely hard to diagnose build failures.

c++ Android NDK and include issues

I am getting into building c++ modules for my apps. I cannot get boost or system to work.
I do the following:
#include <boost>
or
#include <system>
and BOTH things result in "boost no such file or directory" and "system no such file or directory.
I cannot begin to list the things I have attempted because the list is way too long. I have followed multiple links leading me to lots of things. But nothing seems to work. If I can get #include <system> to work then I won't need boost. I would prefer to get #include <system> working for that will allow me to execute command line commands inside my module.
Thanks everyone!
I hope you include stlport_static to the project. I think "APP_STL:=stlport_static" must be in Application.mk file.
Did you see these links:
http://stoflru.org/questions/23783680/android-ndk-include-boost-library
Include Boost C++ library in android
Android NDK: Including boost c++ library

Resources