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).
Related
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.
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.
I am trying to write a C program that will use fork() and wait() in Visual Studio 2013. I have downloaded and installed Cygwin, but I am unable to configure Visual Studio to use the appropriate header files. I'm fairly new to the IDE and I was wondering if this community could help me figure out where I am making a mistake.
When starting a new project, this is what I do:
Create new Visual C++ Win32 Console Application
Add new main.c source file to the project
Right-click project properties and configure Include Directories to
include the Cygwin directory: C:\cygwin64
I've taken a screenshot of where I am trying to configure the properties in case this is where I am making my mistake:
My code is rather simple as I am just trying to get it to run at this point:
#include <unistd.h>
int main() {
int i;
i = fork();
if (i == 0) {
printf("I am the child.");
}
else {
wait(&i);
}
}
Here's a screenshot of the error message I receive when I try to build my project:
I apologize in advance if this is a silly question, but I do appreciate any help that you can offer. If there is anything that I can do on my end to help troubleshoot, please let me know.
The problem is that your current include path C:\cygwin64\bin is equivalent to unix /bin, which is for binaries (aka executables). To use unix headers, you need to use the equivalent of /usr/include, which, for your system, should be C:\cygwin64\usr\include.
Using fork() within a Win32 Console application is not going to work. It's a Unix system call. Cygwin is an emulation of the Linux environment that runs on top of Win32.
As others have said you need to be using the Cygwin toolchain to do your compile and builds.
There may be third party libraries to allow Visual Studio to cross-compile for Cygwin, but a Win32 console application is definitely not what you want if you re making Unix system calls.
Ok, there are lots of pieces here to do this, and there are also a lot of answers here with incorrect information.
First, as some have said, you need to modify your include path to contain your include folder from Cygwin, from your install that appears to be C:\Cygwin64\usr\include.
Next, there is an FAQ on this very thing on the Cygwin site. How do I use cygwin1.dll with Visual Studio or MinGW?
From the page:
Use the impdef program to generate a .def file for the cygwin1.dll (if
you build the cygwin dll from source, you will already have a def
file)
impdef cygwin1.dll > cygwin1.def
Use the MS VS linker (lib) to generate an import library
lib /def=cygwin1.def /out=cygwin1.lib
Create a file "my_crt0.c" with the following contents
#include <sys/cygwin.h>
#include <stdlib.h>
typedef int (*MainFunc) (int argc, char *argv[], char **env);
void my_crt0 (MainFunc f) {
cygwin_crt0(f);
}
Use gcc in a Cygwin prompt to build my_crt0.c into a DLL (e.g. my_crt0.dll).
Follow steps 1 and 2 to generate .def and .lib files for the DLL.
Download crt0.c from the cygwin website and include it in your
sources. Modify it to call my_crt0() instead of cygwin_crt0().
Build your object files using the MS VC compiler cl.
Link your object files, cygwin1.lib, and my_crt0.lib (or whatever you
called it) into the executable.
Note that if you are using any other Cygwin based libraries that you
will probably need to build them as DLLs using gcc and then generate
import libraries for the MS VC linker.
I just started C recently and have been writing some basic C code, but is a bit clueless about how I should go about "installing" libraries like igraph in Visual Studio 2010. I downloaded the igraph "source code for Microsoft Visual Studio" here: http://igraph.sourceforge.net/download.html
(naive) Attempt
There is an "include" folder with all the ".h" files that I copied to the directory that my Visual Studio is set up to look in whenever I use include < something.h > but I get a "unresolved external symbol", which I know means the library isn't set up correctly.
Question
How should I go about "installing" igraph? (and possibly other C libraries)
Look in to the folders of your library, I suppose, you'll find a .lib file there.
Go to your project settings and open the linker settings. Under Input you should find additional dependencies. Add your .lib file(s) there. You also might need to add the folder where this .lib file(s) reside to the library folders (found under VC++-folders).
I have the german version of MSVC here, so your menu entries might be named slightly different, but you will find them ;)
Mark's answer was very helpful, but there were other issues. Following these step resolved it for me. Hopefully this will help someone in the future.
Step 1
The igraph package is a bunch of ".c" and ".h" files that was missing the ".lib" file in Mark's answer. It has to be open and build in Visual Studio. Then, the ".lib" file will appear in the "Debug" folder.
Step 2
Do the steps in Mark's answer.
However, in "VC++ Directories" there is a line call "Include Directories" where you have to store the path to your igraph include directory. This is so that Visual Studio can find the correct files when you write e.g. #include <include/igraph.h>.
Step 3
If you get a "...already defined in MSVCRTD.lib..." error. Then, visit this answer: How to resolve the following linker errors in Visual Studio?
Each of the libraries/subprojects that you are using must be compiled with the same option in "C/C++ -> Code Generation -> Runtime library".
Error message:
fatal error: sal.h: No such file or directory cstudy line 11, external
location: C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Include\specstrings.h C/C++ Problem.
But when I add VC/include to this project,I received a ton of error messages. It seems VC/include/sal.h is not a standard header file for GCC.
The source code is very simple:
#include "windows.h"
int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
return 0;
}
Environment:
Windows 7.0A SDK
VC 2010
MINGW
CDT/ECLIPSE.
Thanks.
No, the sal.h header is not part of GCC / MinGW, however you can add your VC/include/ as an include directory to eclipse.
alternative: move all (!) requried headers to your mingw or project include directory. The one from MinGw is: <mingw path>/include).
Anyway. sal.h, if you install the Windows SDK then it isn't going to
be in the SDK directory, but you should find that if you select to
install the compiler and tools it will get installed along with that.
This is because sal.h is needed in the CRT headers as well as the
Windows headers. So you NEED to install the VS compilers and tools
along with the SDK. You will then find that the compiler will be
installed by default under %ProgramFiles%\Microsoft Visual Studio
2010\VC and sal.h will be in include under that path. On 64 bit
systems it will be under %ProgramFiles(x86)% by default.
source: http://social.msdn.microsoft.com/Forums/eu/windowssdk/thread/0e166050-99f1-436b-bd94-b39e2910f43d
See:
can't find sal.h (!)
Windows SDK header files question
I just ran into this problem. I can't seem to get the sal.h header file through the MS Windows version of mingw, but "yum whatprovides \*/sal.h" on my Fedora Core 18 machine brought up the mingw-headers package. I downloaded the source package (i.e. yumdownloader --source mingw-headers), opened up the .tar.gz file in file-roller, grabbed the sal.h file, and put it in /c/MinGW/include on my MS Windows machine.
The same package had dsound.h, which was the next missing header file.
I've never tried to use mingw under Fedora Core to cross-compile MS Windows apps, but maybe it's time... :-)