I don't seem to be finding anything on this, or quite like this. I have this code that we want working with windows, so I've been using mingw and working to modify the code so it compiles. However, I ran into a big issue. The issue is entirely with Microsoft MPI. Our code includes and uses MPI for parallelization code. When the mingw compiler gets to the mpi portion, it tries to compile mpi.h and fails right away, because the overhead like (MPI_Offset and MPI_Count) are not declared in the header file (IIRC, they're usually done during compile time by mpicc or whatever, but MS-MPI doesn't do things that way, not really sure how it does things), it comes up with a bunch of "has not been declared" errors. How can I fix this? I really have no clue how MS-MPI works and the microsoft resources I've found do not help. I keep seein something about a cross platform mingw compiler, but I'm not sure what that is or how I'd use it. I have pretty much no experience compiling things outside of visual studio, and am only beginning to get familiar with mingw. Even pointers on where to look would be appreciated.
Interestingly enough, adding #include to the top of MS-MPI's mpi.h worked.
You may try mpich2. mpich2-v1.4.1p1 is the last version support windows officically. It also supports the MinGW and gfortran.
As stated in the mpich2's website, the msmpi is just a branch of mpich2 version 1.
Related
I have double checked several times that I am running either C++17 or above, yet this problem keeps occurring and I really don't understand why.
I am simply trying to call a const member function by using std::as_const(), which shouldn't be causing any fuss. Maybe it's missing from the utility library? But how could that be?
If anyone has an idea why this is happening I'd appreciate an answer.
VSCode telling me Utility library doesn't have std::as_const()
To summarize the back and forth in the comments:
Visual Studio Code relies on an external compiler to build and analize sources
Your compiler is the one that is likely old, not Visual Studio Code
Verify that your compiler is current
Update to a new compiler by upgrading MinGW.
In this case OP had an old compiler gcc 6.3.0 from Dec/2016 that did not support the features he wanted.
I've come across an issue whilst trying to compile the latest branch of grpc under MSYS2, using mingw64 as suggested by the official installation guide.
The latest gcc for msys2 is 5.2.0, which isn't exactly on good terms with grpc. Still, downgrading to 4.9.1 helped a bit. Through a lot of manual editing of the makefile and a couple C headers, I was finally able to compile all the dependencies. As far as I can tell, most objects had successfully compiled. However, make keeps failing with the error "no target to make libgrp.dll, required by shared_c"(might not be perfect wording). I end up with botched static libs that are recognized by Qt as lacking symbols.
I would greatly appreciate a reliable compilation guide for grpc, and/or precompiled binaries fit for Qt 5.5 32-bit. I know the project is not too mature just yet, but it looks very promising and I can't wait to work with it!
Many thanks!
You're right that mingw isn't quite a first class citizen for grpc, but it's something we're looking to work on soon. Please file bugs at http://github.com/grpc/grpc/issues for anything you find!
That said, we do test the C codebase against Visual Studio 2013 regularly. I expect C++ to be tested regularly soon, along with VS2015. Could VS2015 be the solution to your problems, given it's now a free download?
I have searched and searched and found no way to get directX to compile under MingW, I've seen others success and tried to replicate it to no avail. I've already read this similar question and it didn't help so please don't direct me to it: How to compile a DirectX 11 app in MinGW.
I've been trying to get MingW to cooperate with directX for a long time now, here is a list of my failed attempts and what I've read worked for others:
Download MSVC headers and have MingW use them
Download MingW-W64 and use it to compile
Download Reubens MingW-W64 and use it to compile
Download the most up to date MingW compiler and use it
Download TDM-GCC and use it.
mix compiler headers in a desperate attempt to make errors go away
I heard that I should be able to at least get to fail at the linker phase if I just dump the directX headers into the appropriate place, but I'm getting syntax errors left and right even after I did that (granted the bulk of them went away.) Each compiler ends up with its own unique errors, failing at different points but appearently succeeding in places where the others fail at some points. What is going on? Why does perfectly valid code (all written by microsoft) suddenly fail to compile when handled by any other compiler?
Unfortunately the samples include with the DirectX June 2010 SDK are far from "perfect valid code". They use a number of extensions specific to Microsoft's compiler.
Before I gave up on it as being essentially hopeless, I found the following Microsoft's specific dependencies when trying to compile the sample in Samples\C++\Direct3D\BasicHLSL:
the __noop intrinsic
the macros __min and __max
various "safe" versions of standard functions, like wsprintf_s and strcpy_s
non-standard pre-processor token pasting
allowing goto across variable initialization
the __uuidof operator
There are also problems with Microsoft's DirectX headers that I haven't mentioned, like being dependent on Microsoft's SAL annotation macros. Arguably though this a failing of MinGW for not having compatible versions of these DirectX headers.
Some of these problems are relatively easy to work around. Others are more difficult and would require rewriting the incompatible parts of the sample. There are also likely to be more Microsoft dependencies in the sample that I didn't discover.
The bottom line is that there's no way to compile the samples included with the DirectX SDK with MinGW or any other port of GCC without first modifying to the samples and the DXUT framework to make them more portable.
Trying to compile a C++ kernel project with MinGW & NASM (formerly DJGPP & NASM). Have actually tried Cygwin too, with the exact same results below:
First, just swapped out \DJGPP\bin for \MinGW\bin. Got the following link error: target coff-go32 not found.
Swapped target to elf32-i386, and got cannot perform PE operations on non PE output file 'build/kernel.elf' This was a bit of a weird error, since to my knowledge I'm not doing any 'PE operations'.
Changed target again, to pe-i386, got a new error build/Common.o:Common.cc:(.text+0x2a): undefined reference to 'atexit'
It seems MinGW is generating atexit calls for static classes. DJGPP did not. The kernel does it's own DTOR handling during shutdown. I am aware that defining atexit would 'solve' this, but that would be more of a hack at this point, and not a longterm solution. I want rather to get MinGW compiling the existing code without any (or minimal) modifications.
Frankly, I'm not that familiar with the Windows build environment and could use any tips on what to do. The project (minus the changes listed above) compiles and boots fine under DJGPP. The difference seems to be in the way DJGGP and MinGW handle compile-time class declarations?
EDIT: Finally broke down and built a cross-compiler on Cygwin. All working now.
You need to build a free-standing cross compiler. This problem has been referenced many times at the OSDev Wiki to the point that most people recommend you begin writing a kernel by first creating a cross compiler.
This article will provide a step-by-step reference to building your own cross compiler. Note, in Windows, you may have to build the cross compiler using MingW or Cygwin
More out of interest than anything else, but can you compile a DirectX app under linux?
Obviously there's no official SDK, but I was thinking it might be possible with wine.
Presumably wine has an implementation of the DirectX interface in order to run games? Is it possible to link against that? (edit: This is called winelib)
Failing that, maybe a mingw cross compiler with the app running under wine.
Half answered my own question here, but wondered if anyone had heard of anything like this being done?
I've had some luck with this. I've managed to compile this simple Direct3D example.
I used winelib for this (wine-dev package on Ubuntu). Thanks to alastair for pointing me to winelib.
I modified the source slightly to convert the wchars to chars (1 on line 52, 2 on line 55, by removing the L before the string literals). There may be a way around this, but this got it up and running.
I then compiled the source with the following:
wineg++ -ld3d9 -ld3dx9 triangle.cpp
This generates an a.out.exe.so binary, as well as an a.out script to run it under wine.
If this is not about porting but creating, you should really consider OpenGL as this API is as powerful as DirectX and much easier to port to Mac or Linux.
I don't know your requirements so better mention it.
You can't link against wine as it's essentially a call interdictor/translator rather than a set of libraries you can hook into. If linux is important go OpenGL/SDL/OpenAL.
I believe(I've never tried this) you can can compile Linux binarys against winelib. So it works just like a Linux executable, but with the windows libraries.
http://www.winehq.org/site/docs/winelib-guide/index
go to the directory with the source and type in:
winemaker --lower-uppercase -icomdlg32 -ishell32 -ishlwapi -iuser32 -igdi32 -iadvapi32 -ld3d9 .
make
wine yourexecutable.exe.so
If you get this Error:
main.c:95:5: error: ‘struct IDirect3D9’ has no member named ‘CreateDevice’
make sure you have named your file main.cpp and not main.c.
There is currently no way to compile DirectX code to directly target Linux. You would build your application like you normally would, then run it using a compatibility layer like Wine/Cedega.
you can compile a directx apps in linux, but not launching it straight away.
if you use a crosscompilator that makes windows exe and point to the windows sdk and directx sdk.
Although this question is dated, I decided to updated on it, because it keeps popping up for me as the first suggestion for this particular problem.
As the previous answers already suggested you can compile against winelib. However, there are yet another two solutions.
The first solution would be either to use the MinGW provided for your distributions. MinGW is a 'cross-compiler', that compiles either from macOS or linux to windows and has support for DirectX. Note, that C++ libraries compiled with MinGW are not compatible with the MSVC compiler's ABI, thus cannot be consumed. However, the resulting binaries can be executed using Wine.
The second solution would be to use clang as a cross compiler. Clang usually includes the Compiler and Linker needed for Windows out of the box. However, it'll require you to include provide the headers and libraries yourself. On the other hand, libraries compiled this way are compatible with MSVC and, thus, can be consumed by it.
Side note:
Latter allows you to setup an CI server using linux (I did so on a raspberry pi), which creates compatible binaries for end users.
Wine is the only way to run DirectX in Linux