VS2019 linux header files

VS2019 linux header files - c

I'm experimenting with developing C code for linux using VS2019.
I'm finding that whilst many Linux headers such as sys/types.h and sched.h are being found OK, others, such as sys/syscall.h and fcntl.h are not being found.
I can see that it has a local copy of many headers such as stdint.h in local linux platform directory...can I just cut and paste the missing ones from the target machine?
I rather suspect that if common headers such as unistd.h are missing there is a reason, and I don't want to mess things up!

From Microsoft's documentation:
By default, Visual Studio does not include any system-level include
files from the Linux computer. For example, items in the /usr/include
directory are not present in Visual Studio. For full IntelliSense
support, you will need to copy those files to some location on your
development computer and point Visual Studio to this location. One
option is to use scp (Secure Copy) to copy the files. On Windows 10,
you can use Bash on Windows to run scp. For previous versions of
Windows, you could use something like PSCP (PuTTY Secure Copy).
You can copy the files by using a command similar to the following:
scp -r linux_username#remote_host:/usr/include .
Of course, replace the linux_username and remote_host values above for
what's appropriate in your own environment.
Once the files are copied, use the VC++ Directories item in Project
properties to tell Visual Studio where to find the additional include
files that were just copied.

Related

Finding DirectX12 libraries with CMake and MinGW

I am trying to use CMake to find DirectX 12 and link it against an executable. What I have so far works when compiling with MSVC, but fails when compiling with GCC:
Could NOT find D3D12 (missing: D3D12_LIBRARIES).
I am using a slightly altered version of the FindD3D12.cmake:
# Find the win10 SDK path.
if ("$ENV{WIN10_SDK_PATH}$ENV{WIN10_SDK_VERSION}" STREQUAL "" )
get_filename_component(WIN10_SDK_PATH "[HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v10.0;InstallationFolder]" ABSOLUTE CACHE)
get_filename_component(TEMP_WIN10_SDK_VERSION "[HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v10.0;ProductVersion]" ABSOLUTE CACHE)
get_filename_component(WIN10_SDK_VERSION ${TEMP_WIN10_SDK_VERSION} NAME)
elseif(TRUE)
set (WIN10_SDK_PATH $ENV{WIN10_SDK_PATH})
set (WIN10_SDK_VERSION $ENV{WIN10_SDK_VERSION})
endif ("$ENV{WIN10_SDK_PATH}$ENV{WIN10_SDK_VERSION}" STREQUAL "" )
# WIN10_SDK_PATH will be something like C:\Program Files (x86)\Windows Kits\10
# WIN10_SDK_VERSION will be something like 10.0.14393 or 10.0.14393.0; we need the
# one that matches the directory name.
if (IS_DIRECTORY "${WIN10_SDK_PATH}/Include/${WIN10_SDK_VERSION}.0")
set(WIN10_SDK_VERSION "${WIN10_SDK_VERSION}.0")
endif (IS_DIRECTORY "${WIN10_SDK_PATH}/Include/${WIN10_SDK_VERSION}.0")
# Find the d3d12 and dxgi include path, it will typically look something like this.
# C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\d3d12.h
# C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\shared\dxgi1_4.h
find_path(
D3D12_INCLUDE_DIR # Set variable D3D12_INCLUDE_DIR
d3d12.h # Find a path with d3d12.h
HINTS "${WIN10_SDK_PATH}/Include/${WIN10_SDK_VERSION}/um"
DOC "path to WIN10 SDK header files"
HINTS
)
find_path(
DXGI_INCLUDE_DIR # Set variable DXGI_INCLUDE_DIR
dxgi1_4.h # Find a path with dxgi1_4.h
HINTS "${WIN10_SDK_PATH}/Include/${WIN10_SDK_VERSION}/shared"
DOC "path to WIN10 SDK header files"
HINTS
)
set(D3D12_INCLUDE_DIRS ${D3D12_INCLUDE_DIR} ${DXGI_INCLUDE_DIR})
# Find D3D libraries
set(D3D12_LIB_NAMES d3d12.lib dxgi.lib d3dcompiler.lib dxguid.lib)
set(D3D12_LIBRARIES)
foreach (D3D12_LIB_NAME ${D3D12_LIB_NAMES})
find_library(${D3D12_LIB_NAME}_LOC NAMES ${D3D12_LIB_NAME} HINTS ${D3D12_HINTS_PATH})
set(D3D12_LIBRARIES ${D3D12_LIBRARIES} ${${D3D12_LIB_NAME}_LOC})
endforeach(D3D12_LIB_NAME)
include(FindPackageHandleStandardArgs)
# handle the QUIETLY and REQUIRED arguments and set D3D12_FOUND to TRUE
# if all listed variables are TRUE
find_package_handle_standard_args(
D3D12 DEFAULT_MSG
D3D12_INCLUDE_DIRS D3D12_LIBRARIES
)
mark_as_advanced(D3D12_INCLUDE_DIRS D3D12_LIBRARIES)
And then linking it with: target_link_libraries(<name> ${D3D12_LIBRARIES}).
The D3D12_INCLUDE_DIRS variable is set to the correct value, the problem is only with the libraries.
Are the DirectX 12 libraries not compatible with GCC and CMake is smart enough to figure that out, or am I doing something wrong when trying to find them?
Edit:
As the answer mentioned, the FindD3D12.cmake module is not needed. The DirectX libraries are system libraries when compiling on Windows, so doing target_link_libraries(<name> PRIVATE d3d12.lib dxgi.lib d3dcompiler.lib dxguid.lib) works.

======================================================
Windows:
DirectX is part of the Windows SDK.
If you have are compiling on Windows there is no way you aren't using the SDK to compile. Therefor don't worry about handling the include directories and whatnot.
Therefore you can treat the Directx libraries as regular system libraries and the following command will work. That's the magic of cmake.
So most of your cmake isn't really necessary. At least if you are using visual studio.
If you aren't using visual studio you might need to write up a toolchain (https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html?highlight=cmake_cxx_compiler_id#cmake-toolchains-7)
# DX12 libraries
target_link_libraries(foobar PRIVATE
d3d12.lib
dxgi.lib
dxguid.lib
)
======================================================
Linux:
Secondly DirectX12 will have linux support:
https://devblogs.microsoft.com/directx/directx-heart-linux/
However I don't think it allows use of graphics functionality, just the compute functionality. But regardless assuming Microsoft didn't make it extremely painful the cmake should be roughly similar.
======================================================
Lastly if you wanna know what version of the SDK you are building against check out CMAKE_SYSTEM_VERSION
On windows setting this before the first project call sets the SDK version. Because that's what the SDK versions stand for. Versions of windows builds.
Also to be extra cautious add extra static_asserts in your codebase to make sure you are using a version of the SDK you intended you'll want to include "Windows.h" which you probably already have anyway. And then check for the compiler definitions that tell you what Version of the Windows OS you are compiling.
"When you use the Windows SDK, you can specify which versions of Windows your code can run on. The preprocessor macros WINVER and _WIN32_WINNT specify the minimum operating system version your code supports. Visual Studio and the Microsoft C++ compiler support targeting Windows 7 SP1 and later. Older toolsets include support for Windows XP SP2, Windows Server 2003 SP1, Vista, and Windows Server 2008. Windows 95, Windows 98, Windows ME, Windows NT, and Windows 2000 are unsupported." - Microsoft Documentation (https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-160)

Are the DirectX 12 libraries not compatible with GCC
Every compiler has its own library format, cl uses .lib libraries and gcc uses .a and .so libraries. You can't just take cl's libraries (which is what is stored in the Windows SDK) and feed them to gcc.

Bash for Windows 10 gcc won't compile c files pasted into the root directory

As the title suggests, if I paste a c file written somewhere else into the root directory of the Linux Subsystem, I can't compile it.
I did a test where I made two differently titled hello world programs: one in vi that I can get into from the bash interface, and one elsewhere. When I compiled the one made in vi, it worked fine. Trying to do so for the one made elsewhere (after pasting it into the root directory), however, resulted in this:
gcc: error: helloWorld2.c: Input/output error
gcc: fatal error: no input files
compilation terminated
Any help with this would be much appreciated.

Do not change Linux files using Windows apps and tools!
Assuming what you meant by "paste a C file written somewhere else into the root directory of the Linux subsystem" is that you pasted your file into %localappdata%\lxss, this is explicitly unsupported. Files natively created via Linux syscalls in this area have UNIX metadata, which files natively created with Windows tools don't have.
Use /mnt/c (and the like) to access your Windows files from Linux; don't try to modify Linux files from Windows.
Quoting from the Microsoft blog linked at the top of this answer (emphasis from the original):
Therefore, be sure to follow these two rules in order to avoid losing files, and/or corrupting your data:
DO store files in your Windows filesystem that you want to create/modify using Windows tools AND Linux tools
DO NOT create / modify Linux files from Windows apps, tools, scripts or consoles

You cannot copy (by default, who knows how Windows bash is set up!) files into the root directory! Your gcc error is say "no input files", so the copy has most likely failed. Copy the files to your home directory instead, for instance:
cp helloWorld2.c ~/
instead of:
cp helloWorld2.c /

Statically link libraries into a dynamic library (dll) [duplicate]

I'm working on a C++ application for Windows that uses OpenSSL 1.0.1e library. I'm on Visual Studio 2008.
For portability reasons my application is statically linked against runtime libraries (/MT and /MTd options). And I don't ship runtime libs with my application.
Per the OpenSSL FAQ, the library is by default linked against multithreaded DLL runtime (/MDd) which is obviously incompatible with my scenario. So to make my program work I've added applink.c to my project. On my dev machine and on most test computers the program works fine.
But unfortunately I've located computers where the app doesn't start. Windows displays error:
The application failed to initialize properly (0xc0150002). Click on OK to
terminate the application.
I've opened libeay32.dll in Dependency Walker and I see that MSVCR90.dll is not found. So the trick with applink.c doesn't really work for me.
How do I build OpenSSL with /MT or /MTd option?

Use the nt.mak makefile rather than the ntdll.mak makefile.
As an aside, I have written some scripts around the standard OpenSSL build scripts which make it 'easier' (for me at least) to use OpenSSL on Windows with a mix of both x86 and x64, you can get them from here.

To build 64-bit OpenSSL statically linked (which results in a single .exe file without any DLLs) with Visual Studio 2015, you will need the following prerequisites:
Git for Windows. You can download it at https://git-scm.com/download/win. This guide uses version 2.11.0.3.
Strawberry perl. You can download it at http://strawberryperl.com/ (Warning: ActivePerl is highly not recommended. It will give you strange errors during the process). This guide uses version 5.24.1.1.
NASM assembler, which is available from http://www.nasm.us/. This guide uses version 2.12.03rc1.
You are expected to install all those tools system-wide and add them to your %PATH% environmental variable.
After you got everything we need, just follow this simple steps:
Open VS2015 x64 Native Tools Command Prompt from your Start Menu. You will see command prompt.
Create C:\build directory and issue the following command in the command prompt:
cd c:\build
Download latest zlib & OpenSSL source codes to your build dir by using the following commands:
git clone https://github.com/madler/zlib
git clone https://github.com/openssl/openssl
First we have to build static zlib. To do that first we will need to edit some configuration files:
Navigate to the zlib source folder: cd C:\build\zlib
Edit the win32\Makefile.msc file:
Find the line starting with CFLAGS
Replace -MD with -GL -MT -Zc:wchar_t-
Find the line starting with LDFLAGS
Replace -debug with -opt:icf -dynamicbase -nxcompat -ltcg /nodefaultlib:msvcrt
Build zlib using the following command (should take less than a minute):
nmake -f win32/Makefile.msc AS=ml64 LOC="-DASMV -DASMINF -DNDEBUG -I." OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
Copy resulting files to your OpenSSL directory:
xcopy zlib.h C:\build\openssl\
xcopy zconf.h C:\build\openssl\
xcopy zlib.lib C:\build\openssl\
xcopy zlib.pdb C:\build\openssl\
Navigate to OpenSSL source: cd C:\build\openssl\ and configure it to use static zlib & read configuration files (openssl.cnf) from C:\Windows\ directory.
perl Configure VC-WIN64A no-shared zlib no-zlib-dynamic threads --prefix=C:\Windows\
Now make the following edits to the C:\build\openssl\makefile:
Find the line that starts with: CFLAG
Append: /Zc:wchar_t- /GL /Zi
Find the line that starts with: LDFLAGS
Replace /debug with /incremental:no /opt:icf /dynamicbase /nxcompat /ltcg /nodefaultlib:msvcrt
Find the line that starts with: EX_LIBS
Replace ZLIB1 with zlib.lib
Save changes
Build OpenSSL by issuing the nmake command (will take around 15 minutes).
The resulting ~3MB openssl.exe file will be located at C:\build\openssl\apps\ directory. It is fully portable, since all DLLs are included. If you need to use custom configuration file, copy C:\build\openssl\apps\openssl.cnf to your C:\Windows\ directory & edit it to your liking.

The most elegant option I have found for Windows involves using the scripts provided at http://p-nand-q.com/programming/windows/building_openssl_with_visual_studio_2013.html
They provide scripts for VS2010/VS2013/VS2015 for each script version it builds all combinations of x86/x86-64 with runtimes MDd/MD/MTd/MT.
Quoting the instructions:
PREREQUISITES:
The script assumes you are on Windows.
The script assumes you have Visual Studio 2010, 2013 or 2015 installed
in all the usual places. Important: If you have a different
installation folder, your mileage may vary
The script assumes you have downloaded an OpenSSL tarball, like this
one.
The script assumes you have Python (2.7 or 3.x) installed and on your
PATH
The script assumes you have 7-zip installed (doesn't need to be on
your PATH) Choose the script you want to use and edit it. For example,
let's take a look at the top of rebuild_openssl_vs2015.cmd:
T:
set OPENSSL_VERSION=1.0.1p
set SEVENZIP="C:\Program Files\7-Zip\7z.exe"
set VS2015="C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\bin\vcvars32.bat"
set VS2015_AMD64="C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\bin\amd64\vcvars64.bat"
so it is pretty easy to see: you must enter the OpenSSL version
manually, the rest should have sensible defaults...
Note: The script uses the SUBST T:\ drive for building OpenSSL.
I tested and it works, in less than 10 min! KUDOS for the authors of the scripts!!
UPDATE: For the x64 builds to be generated you need to install nasm assembler and have it in the PATH.

If you want precompiled OpenSSL libraries with MT look here: http://www.npcglib.org/~stathis/blog/precompiled-openssl/
You will find a patch for the OpenSSL sources that enables producing libraries with suffixes MT/MD and "d" for debug to make identifying the libraries easier.
What's more, you will also find the actual build script to build all of them at once for many different version of Visual Studio. I build and use them myself to exactly produce binaries that need no DLLs for my projects and you may find them useful.

It appears OpenSSL now links with -MT -Zl (at least when using msvc) meaning it discards default named libraries which are then decided in your final binary. Applications appear to use the static runtime by default.
In other words, no action needs to be taken in order to use it with your binary, just provide whatever flag you want and the OpenSSL library will just work with it. Unfortunate there isn't a lot of concrete documentation on building such an important library.

I solved this problem by manually editing the ntdll.mak file. You only need to change two lines:
in the CFLAG line change /MD with /MT
in the EX_LIBS line append these libraries: libcmt.lib libvcruntime.lib
Save the makefile then run nmake as per OpenSSL instructions.
You can check that the Windows runtime dependencies has been removed with these commands (VS Command Line):
dumpbin /dependents out32dll\libeay32.dll
dumpbin /dependents out32dll\ssleay32.dll

using linux header files in visual studio

I was trying to use linux kernel header file on the visual studio 2013.
I want to do this for auto completion purpose.
I noticed that stdio.h file is inside of the C:\Program Files\Visual Studio 12.0\VC\crt\src,
So I copied my linux folder, which contains kernel header files, into the src folder.
However, Visual studio does not seem to find these header files.
For example:
#include <linux/kernel.h>
It says Error: cannot open source file "linux/kernel.h"
I tried to change all slash characters into back slash, however, it does not fix the issue.
What do I have to do if I want to make visual studio know this header file is existed?
I know I could move my kernel.h to my current folder and use #include "kernel.h"
However, I would like to keep the system header files in my computer and
use with #include <linux/kernel.h> when it is needed.

#include <kernel.h>
and add C:\Program Files\Visual Studio 12.0\VC\crt\src\linux to the include path (if one is using VS2017 which shipped with it).
To obtain the kernel.h file, i.e. kernel source, determine the kernel version one needs and obtain the src from kernel.org, e.g. 5.4.26

In Visual Studio 2015, the alternative is to install the Visual C++ for Linux Development and the Visual C++ for Android Development templates. At time of writing the Linux headers are only present in the Android development folder, on my machine it was C:\ProgramData\Microsoft\AndroidNDK64\android-ndk-r10e\platforms\android-21\arch-x86_64\usr\include. Add that path to the include path and Intellisense works for common Linux files like <sys/socket.h>.

Current location(s) under VS 2017 with Android files in a separate tree, 32 and 64 bit:
C:\Microsoft\AndroidNDK{,64}\android-ndk-r{NDK_VER}c\platforms\android-{P_VER}\arch-x86{,_64}\usr\include
NDK_VER -- versions of the NDK, currently 12,13,15
P_VER -- target android platform version (aka level), currently the highest is 26
Examples:
C:\Microsoft\AndroidNDK\android-ndk-r15c\platforms\android-26\arch-x86\usr\include
C:\Microsoft\AndroidNDK\android-ndk-r15c\platforms\android-26\arch-x86_64\usr\include
C:\Microsoft\AndroidNDK64\android-ndk-r15c\platforms\android-26\arch-x86\usr\include
C:\Microsoft\AndroidNDK64\android-ndk-r15c\platforms\android-26\arch-x86_64\usr\include
This reflects general "new style" in VS with build platforms and target platforms being separated and orthogonal. There are also arch-{arm,mips}{,64} so 6 folders under arch target platform version.
Include files are the same in AndroidNDK and AndroidNDK64 and under one NDK version only files under machine and asm folders are different (for Intel and Mips even files under asm are identical for 32 and 64 bits).

How do I build OpenSSL statically linked against Windows runtime?

I'm working on a C++ application for Windows that uses OpenSSL 1.0.1e library. I'm on Visual Studio 2008.
For portability reasons my application is statically linked against runtime libraries (/MT and /MTd options). And I don't ship runtime libs with my application.
Per the OpenSSL FAQ, the library is by default linked against multithreaded DLL runtime (/MDd) which is obviously incompatible with my scenario. So to make my program work I've added applink.c to my project. On my dev machine and on most test computers the program works fine.
But unfortunately I've located computers where the app doesn't start. Windows displays error:
The application failed to initialize properly (0xc0150002). Click on OK to
terminate the application.
I've opened libeay32.dll in Dependency Walker and I see that MSVCR90.dll is not found. So the trick with applink.c doesn't really work for me.
How do I build OpenSSL with /MT or /MTd option?

Use the nt.mak makefile rather than the ntdll.mak makefile.
As an aside, I have written some scripts around the standard OpenSSL build scripts which make it 'easier' (for me at least) to use OpenSSL on Windows with a mix of both x86 and x64, you can get them from here.

If you want precompiled OpenSSL libraries with MT look here: http://www.npcglib.org/~stathis/blog/precompiled-openssl/
You will find a patch for the OpenSSL sources that enables producing libraries with suffixes MT/MD and "d" for debug to make identifying the libraries easier.
What's more, you will also find the actual build script to build all of them at once for many different version of Visual Studio. I build and use them myself to exactly produce binaries that need no DLLs for my projects and you may find them useful.

It appears OpenSSL now links with -MT -Zl (at least when using msvc) meaning it discards default named libraries which are then decided in your final binary. Applications appear to use the static runtime by default.
In other words, no action needs to be taken in order to use it with your binary, just provide whatever flag you want and the OpenSSL library will just work with it. Unfortunate there isn't a lot of concrete documentation on building such an important library.

I solved this problem by manually editing the ntdll.mak file. You only need to change two lines:
in the CFLAG line change /MD with /MT
in the EX_LIBS line append these libraries: libcmt.lib libvcruntime.lib
Save the makefile then run nmake as per OpenSSL instructions.
You can check that the Windows runtime dependencies has been removed with these commands (VS Command Line):
dumpbin /dependents out32dll\libeay32.dll
dumpbin /dependents out32dll\ssleay32.dll

Develop Reference

c reactjs sql-server angularjs arrays wpf database batch-file google-app-engine silverlight