I'm trying to identify Windows version using IsWindows10OrGreater() and other related functions.
C++, Windows 7 Home Basic, Visual Studio Code v1.36.1, VSCode Extensions - C/C++ for Visual Studio Code, MinGW g++ v8.2.0
Compilation command:
g++ -std=c++11 main.cpp -o file.exe -s -lws2_32 -Wno-write-strings -fno-exceptions -fmerge-all-constants -fpermissive -static-libstdc++ -static-libgcc
I included the version helper header using #include <Versionhelpers.h>, but IntelliSense doesn't recognize it and the build also fails with the error:
fatal error: Versionhelpers.h: No such file or directory
#include <Versionhelpers.h>
I tried including the header in a fresh file and building it, but that didn't work either.
#include <Versionhelpers.h>
int main() {
IsWindowsServer();
return 1;
}
Is there any extension that I need to install in VSCode to get this to work? Or perhaps download the header file (and put it where?)
Related
I struggled with finding documentation on compiling a basic OpenGL/GLFW example Windows using Cygwin-g++ so I decided to post an answer to my own question.
OS: Windows (10)
Compiler: Cygwin g++ (x86_64-pc-cygwin)
Code: GLFW Documentation's Example Code (basic working example shown below. Won't create a window but should output text if everything builds/links correctly):
#define GLFW_DLL
#include <GLFW/glfw3.h>
#include <iostream>
int main(void) {
std::cout << "Code works" << std::endl;
if (!glfwInit())
return -1;
glfwTerminate();
return 0;
}
Compilation: g++ -Wall -Iinclude main.cpp -o main.exe -L<folder glfw3.dll is in> -lglfw3 -lopengl32 -lgdi32
Issues
Code would compile and build but no output window would appear
My current linking is fine, but different combinations would result in undefined reference errors.
alternative solution building the GLFW for Cygwin
Download glfw-3.3.4.zip and then
$ unzip glfw-3.3.4.zip
$ cd glfw-3.3.4
$ ccmake .
set BUILD_SHARED_LIBS to ON. Configure and generate
$ make
$ make install
Install the project...
-- Install configuration: ""
-- Up-to-date: /usr/local/include/GLFW
-- Up-to-date: /usr/local/include/GLFW/glfw3.h
-- Up-to-date: /usr/local/include/GLFW/glfw3native.h
-- Up-to-date: /usr/local/lib/cmake/glfw3/glfw3Config.cmake
-- Up-to-date: /usr/local/lib/cmake/glfw3/glfw3ConfigVersion.cmake
-- Up-to-date: /usr/local/lib/cmake/glfw3/glfw3Targets.cmake
-- Up-to-date: /usr/local/lib/cmake/glfw3/glfw3Targets-noconfig.cmake
-- Up-to-date: /usr/local/lib/pkgconfig/glfw3.pc
-- Up-to-date: /usr/local/lib/libglfw.dll.a
-- Up-to-date: /usr/local/bin/cygglfw-3.dll
So you will have a proper Cygwin build installed under /usr/local
after that, running under X server
$ g++ main.cpp -o main -lglfw -L/usr/local/lib
$ ./main.exe
Code works
This answer is a summary of the solution from University of Michigan's EECS 487 building OpenGL/GLFW Apps
Install verification
Check that these files are present under the cygwin64 directory.
header files: /usr/include/w32api/GL
static libraries: /lib/w32api/lib{opengl,gdi}32.a
Install GLFW Binaries
GLFW Binaries
Copy Files from the GLFW Binaries into Cygwin
In \cygwin64\usr\x86_64-pc-cygwin\ paste the include file from the GLFW binaries include file. You should have \cygwin64\usr\x86_64-pc-cygwin\include\GLFW with the .h files inside
In C:\cygwin64\usr\x86_64-pc-cygwin\lib paste libglfw3.a and libglfw3dll.a from the lib-mingw-w64 folder of the GLFW binaries
In \cygwin64\usr\x86_64-pc-cygwin\bin paste glfw3.dll from the aforementioned folder
Add \cygwin64\usr\x86_64-pc-cygwin\bin to PATH
To compile g++ -Wall -Iinclude main.cpp -o main.exe -LC:\cygwin64\usr\x86_64-pc-cygwin\bin -lglfw3 -lopengl32 -lgdi32 (change -L to wherever your cygwin is stored).
Etc
The first link has instructions for building with the MingW toolchain specifically, as well as with Linux, MacOS, and Visual Studios
I have the main.cpp on Windows at C:\repo\pdfium\out\debug\obj\test directory. Pdfium.lib is at obj directory.
#include <stdio.h>
#include <fpdfview.h>
int main() {
FPDF_InitLibrary();
FPDF_DestroyLibrary();
printf("PDFium hello.\n");
return 0;}
pdfium.lib is build with GCC(is_lang=false)
With command i am producing main.o
g++.exe -std=c++11 -g -I........\public -c
C:\repo\pdfium\out\debug\obj\test\main.cpp -o obj\Debug\main.o
With command bellow i am trying to link pdfium.lib
g++.exe -o bin\Debug\test.exe obj\Debug\main.o ..\pdfium.lib
But i am taking ...
Warning: corrupt .drectve at end of def file
..\pdfium.lib(obj/core/fpdfapi/parser/parser/fpdf_parser_utility.obj):(.xdata[$unwind$?_Makestr#_System_error#std##CA?AV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##2#Verror_code#2#V32##Z]+0x8): undefined reference to `__GSHandlerCheck'
I have try so many time but nothing on linking on windows 10.
Any advice will be redemptive.
Thank you
Jim
If you're building PDFium with a non-component build (is_component_build = false in args.gn) and not setting pdf_is_complete_lib = true, the generated .lib files won't have their dependencies included, so you're quite likely to have the linker complain about missing symbols. Try either generating DLLs (is_component_build = true) or setting pdf_is_complete_lib = true.
If you use a component build, you'll need to package the PDFium DLL and its dependencies (at least the zlib DLL, possibly others) with your application.
I have both MinGW gcc and Clang clang installed and added to path via chocolatey, and both can be found on the command line. However, when I try to use clang with gcc, clang doesn't seem to know where to find header files in the standard library (such as iostream), returning the following error:
clang++ -v main.cpp -o main.exe -std=c++14 -target x86_64-mingw64
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-unknown-windows-gnu
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
(SKIP)
ignoring nonexistent directory "(nonexistent directories)"
#include "..." search starts here:
#include <...> search starts here:
C:\Program Files\LLVM\lib\clang\9.0.0\include
End of search list.
main.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^~~~~~~~~~
1 error generated.
shell returned 1
I've added both gcc and clang to path, as well as the directory containing header files included in gcc (C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\lib\gcc\x86_64-w64-mingw32\8.1.0), so I don't understand why clang isn't looking in the right place for the header files. How can I fix this problem? And this isn't really necessary, but can the default target for clang be changed? The current Windows 10 default for clang is msvc, but I'd rather not use it.
Solution:
edit your path environment, move or add [path to your g++ folder] to some position ahead of "C:\ProgramData\Chocolatey\bin".
Reason:
LLVM installed using prebuilt binaries from chocolatey or its offcial website lacks header files, therefore it has to use header files of other compiles such as MSVC or mingw64. When you specify your target as mingw64, clang will guess path to header files of mingw by the position of g++.exe (maybe gcc.exe).
Chocolatey uses a software shimgen to "map" (I don't know if there is more proper word) executable file to "C:\ProgramData\Chocolatey\bin", which is placed before [path to your g++ folder]. Therefore clang will detect "g++.exe" under that path first and infer a wrong path from it.
Please forgive my poor English.
I am working in a small laberinth game using C++. My problem: I like Visual Studio Code for Linux, and when I run my program, I get the following error:
main.cpp:2:10:fatal error: Player.h: No such file or directory
include "Player.h"
I set this project using the following folder structure:
Game
|-------include
|----------GameMap.h
|----------Map.h
|----------MapCell.h
|----------Player.h
|-------src
|----------GameMap.cpp
|----------Map.cpp
|----------MapCell.cpp
|----------Player.cpp
|-------main.cpp
This project ran in another computer I was using, and it runs also when I use codeblocks. BUt since I like to keep working in visual code, I would like to be able to compile and run my C++ code when working from Visual Studio code.
g++ -o main main.cpp
edit:
c_cpp_properties.json
{
"configurations":[
{
"name":"Linux",
"includePath":[
"${workspaceFolder}/**",
"/home/roger/Documents/01.Curso_de_CPP/Projecto/Game_02/Headers/include/**"
],
"defines":[
"_DEBUG"
],
"forcedInclude":[
"/home/roger/Documents/01.Curso_de_CPP/Projecto/Game_02/Headers/include/Player.h"
],
"compilerPath":"/usr/bin/gcc",
"cStandard":"c11",
"cppStandard":"c++17",
"intelliSenseMode":"clang-x64"
}
],
"version":4
}
Although I sti
ll don't understand the Linker problem, I was able to solve it using this:
g++ -o main main.cpp bin/Player.o -std=c++0x -Iinclude
by reading the answer to this post:
What's the point of including -std=c++0x in a G++ compile command?
When I had Clang 3.7 installed it would find the STL headers from my GCC installation as long as only both those two directories in the path.
Now that I have installed Clang 3.8 the compiler keeps finding the Visual Studio headers despite the fact that it isn't even in the path
My path is as follows:
PATH=whatever;G:\Compilers\LLVM\bin;g:\compilers\Mingw64-64bit\bin
Edit 1
I've know idea what the correct include paths, but I tried a compilation in Codelite which found these:
"-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include\\c++"
"-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include\\c++\\x86_64-w64-mingw32"
"-IG:\\Compilers\\Mingw64-64bit\\lib\\gcc\\x86_64-w64-mingw32\\5.1.0\\include"
"-IG:\\Compilers\\Mingw64-64bit\\lib\\gcc\\x86_64-w64-mingw32\\5.1.0\\include-fixed" "-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include"
"-IG:\\Compilers\\Mingw64-64bit\\x86_64-w64-mingw32\\include\\c++\\backward"
I'm also using the dialect flag --std=c++11
However a very simple program using the C++ library is giving me errors such as
G:\Compilers\Mingw64-64bit\x86_64-w64-mingw32\include\c++\bits/stringfwd.h:63:33: error: use of undeclared identifier 'char16_t'
template<> struct char_traits<char16_t>;
^
Edit 2
Now passing x86_64-w64-mingw32 as recommended by Martin, the autodiscovery process seems to work, however the produced executable just freezes.
I found the same when I tried to use the VS2015 Clang toolset
The code example I am using is this
#include <iostream>
int main()
{
int arr[] = {1, 2, 3, 4, 5};
for(auto el : arr)
{
std::cout << el << std::endl;
}
return 0;
}
I am now compiling with:
clang++ -v --target=x86_64-w64-mingw32 hello.cpp -o test.exe -std=c++14
I have looked at the executable produced with Dependency Walker and it is showing as a 64 bit compile and linking to "g:\Compilers\Mingw64-32Bit\bin\libstdc++-6.dll"
I think the next step would be to try compiling a 32 bit version, but I cannot seem to find the correct target name for that
I have just tried clang++ hello.cpp -o main.exe -std=c++14 --target=i686-pc-mingw32 -v
That seems to be producing a 32 bit executable, but again it just freezes
Note I updated the path to point to the 32 bit clang.
Edit 3
What I find confusing is that until I passed x86_64-w64-mingw32 as the target I got very similar errors both from passing the GCC paths, and from the default target of MSVC where both seemed to be related to char16_t and similar types
Seeing this I thought I would try if passing a target might fix the VC compiler errors
Whilst that sort of seems to work it just creates more problems, because it keeps asking for libs to link to and I don't know the correct ones
So I tried:
clang++ hello.cpp -o main-vc.exe -std=c++14 --target=x86_64-pc-windows-msvc19.0.0 -v
-Xlinker "c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\libcmt.lib"
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\libcpmt.lib"
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\libvcruntime.lib"
"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10586.0\ucrt\x64\libucrt.lib"
I have no idea what were the correct directories to pass.
I have a feeling that I need to pass another lib file as I am getting this error
libcmt.lib(thread_safe_statics.obj) : error LNK2019: unresolved external symbol __imp_CloseHandle
Did you change the target? VC is the new default. Use this (example) for x64, mingw:
clang++ --target=x86_64-w64-mingw32 test.cpp
Don't forget the linker as wel.