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... :-)
Related
I have just installed MinGW
This is the code
#include<stdio.h>
int main() {
printf("Hello, world!");
return 0;
}
I am getting this error:
In file included from c:\mingw\include\_mingw.h:73:0,
from c:\mingw\include\stdio.h:56,
from main.c:1: c:\mingw\include\w32api.h:59:23: fatal error: sdkddkver.h: No such file or directory #include <sdkddkver.h>
^ compilation terminated.
This looks like a problem with your mingw install, missing dependencies, or environment. Your C code is 100% correct so it's not really a "C" language question at all.
Typically... the only thing that REQUIRES mingw is compiling pre-existing Linux code for distribution on Windows.
If that's really what you need you could:
Try installing Windows SDK to see if it resolves. The missing header: sdkdkver.h is part of Windows SDK (per a very quick google search).
Uninstall mingw & re-install with different instructions.
I've had decent success with cygwin in the past. Looks like MSYS2 is a viable alternative that's more dedicated to building windows "native" SW.
Could dig through mingw documentation on environment variable setup. Maybe missing something there.
Alternatives if you DON'T need to compile + distribute existing Linux source for Windows:
Target Windows directly. Free versions of Visual Studio support compiling C or C++ code. So if you're writing FOR WINDOWS, this is your best bet.
Could use Windows Subsystem For Linux ... if you're just looking run Linux SW or do Linux SW development on a natively windows machine.
I want to install the GSL library (https://www.gnu.org/software/gsl/) in windows. I have downloaded the files but i do not know what to do apart from that in order to be able to use the functions of the library (apart from the #include <...> in my program.c file).
I am using visual studio code and i have installed mingw.
Thanks in advance
EDIT
I am adding more information about this issue. I am not the original poster, but I have the same problem.
I am trying to use the GSL and I work with Visual Studio Code on Windows 10.
I have already installed the basic packages to work with C/C++ in
Visual Studio Code. More precisely, if I am not wrong, VS Code is
using the compiler gcc.exe from mingw64 (last version). This was
installed using an 'extension' available at VS Code (https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools).
I downloaded the last version of the GSL (2.7) and unzipped it.
I get stuck when I try to follow the installation instructions. When I
execute either .\configure or ./configure in the DOS command line,
I get an error of "unknown command" (even if I am placed in the same directory where the file is stored).
When I execute .\configure in PowerShell, I get a message asking me
which programme should be used to open this file.
And here is where I get lost. :/
I have discovered an alternate path, which is installing GSL from vcpkg (https://vcpkg.io/). This is suggested by VS Code, actually. This vcpkg seems to be a programme by Microsoft to make it easier to install third-party C/C++ packages in Windows.
The specifications to install vcpkg are (https://vcpkg.io/en/getting-started.html):
Windows 7 or newer
Git
Visual Studio 2015 Update 3 or newer
I can try this path, but first I would like to be sure there is no easier way (installing Visual Studio to not really use it seems a lot to me!).
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.
Can't build driver, Visual Studio 2012
error C1083: Cannot open include file: 'fltKernel.h': No such file or directory
You need to add
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17134.0\km
to
Additional Include Directories
in C/C++ / General
I assume that's with the Windows 8 WDK? Just make sure that the header was installed in your kits header directory ("C:\Program Files (x86)\Windows Kits\8.0\Include\km"). Also note that fltKernel.h is a kernel mode header, so you can only include it in kernel mode driver projects.
If the header is missing from your installation, I'd recommend reinstalling the WDK. If it is not missing and it still isn't found for some reason, you could try manually adding its absolute path to your list of included headers to see if it fixes the issue. If that works (it should), then you can figure out why it was missing from your include path in the first place.
The file is part of the windows driver kit, likely you need to configure your build tool to use the correct windows SDK. (and also make sure you have go through your setup on Visual Stdio to add the SDK)
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).