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
Related
This question already has answers here:
Can I program for Macs without owning one?
(3 answers)
Closed 3 years ago.
Recently I have been working on creating a game using Visual C++ 2017 and SDL2. I want to make my game accessible to users on all different kinds of systems, not just Windows. I tried starting with making my game also usable on Mac OS, but I cannot figure out any ways of doing this. I figured the best method would be to get Visual Studio to compile my code into a file type like ".APP" rather than ".EXE" since I don't own any form of Mac or Apple computer that can use software made to create apps for Mac. However, I cannot figure out how to change the options in Visual Studio to compile the code into a different file type or even if doing so is possible.
I've searched all over the internet for methods of converting ".EXE" to other file types, using different C++ compilers for compiling into Mac-compatible files, etc. but I haven't been able to find anything that works without requiring a virtual machine or having a physical Mac computer (neither of which I've tried yet since it would take a lot of effort and I'd like an easier solution).
If anybody could tell me how to change the type of file that Visual Studio compiles your code into or if they could suggest a different compiler that works on Windows, is compatible with SDL2, and can compile C++ code into file types that work on Mac computers like ".APP", that would solve my problem. Thank you in advance!
You need to compile your code on all the different platforms you want to support. Using a compiler supported on each of those platforms.
Code compiled on one platform can not run on another (except cross compiling, see below, but that's painful).
Cross compiling is an option on some platforms and with some compilers, but it's usually more pain than gain if you can in any way set up a local tool chain. Cross compilers generate code for a different platform than you are currently running, but getting that working can be hard. And you then also have no way to test your code on the target platform (unless you have one, in which case native compiling would just be easier in the first place).
You should automate the building of your code on different systems with different compilers in your Continuous Integration systen (CI) btw. So you always know after you push a commit, on what platforms it fails and why.
Easiest way forward (IMHO): Buy a cheap Mac. Buy a cheap PC and install Linux on it. Setup a CI system to build all code you commit to your code repository on all your systems (Windows, Mac, Linux) and make it scream at you when the build fails. Also use that system to build installable packages for each platform and again, scream when that fails.
Do the same for all your unit tests.
That's the only serious way to go forward supporting multiple platforms.
I'd really appreciate some help getting HElib to work on Windows 10 x64 using the MSVC 2017 compiler. I successfully managed to compile its dependency, NTL, using the same compiler by following this tutorial and also ran its tests, so it seems to work well.
However, in the case of HElib I tried generating Visual Studio projects using cmake and then compiled it successfully (see NOTE below), but running it fails. For example, I ran the Test_binaryCompare.cpp_exe test (has its own vcproj generated by cmake), but it fails because it reaches a part of code I doubt it's supposed to (it attempts to do an operation called bootstrapping and it is disabled for that test). However, on Linux it works.
LINUX: The reason I'd really like to run this on Windows is because I find it a lot easier to debug using Visual Studio. I'm also more used to Windows overall..
NOTE: Compiling HElib successfully required some modifications like fixing broken tr1 includes (e.g it was trying to include <tr1/memory> instead of just memory although the latter was actually available), suppressing the 4146 error (I also had to do this for NTL) and fixing two instances of variable-length arrays which Microsoft's compiler sadly does not support.
Without any error messages I can't really help you figure out your exact issues but I ported HElib to Windows some time ago: https://github.com/AlexanderViand/HElib/tree/Windows
It's a bit out of date but if the tests works in that version you can check the changes I made against your changes.
There's also the option that you're simply running into this issue: https://github.com/shaih/HElib/issues/228
If your linux version of NTL is slightly older, it might just be that your windows version of NTL is the buggy one.
Finally, I'd very much recommend against running HElib on Windows because without GMP it seems painfully slow.
Instead I ended up setting up a docker virtual machine and SSH'd into that from visual studio: https://hub.docker.com/r/alexanderviand/visual-studio-linux-build-box-with-helib/
Currently I'm using WSL and CLion (which supports WSL quite well) when I'm working with HElib on Windows.
I am quite new to programming, and was working on a project at school which I hoped to take home and complete, and so I copied all the files (including that of code::blocks) thinking that I would simply be able to get it up and running quickly! However when I open the file and attempt to run the program I get a list of errors such as:
undefined reference to '_Unwind_SjLj_Register'
undefined reference to '_Unwind_SjLj_Resume'
undefined reference to '__gxx_personality_sj0'
undefined reference to '_Unwind_SjLj_Unregister'
and many more..
I assume this problem is likely caused by missing files since the computer I copied it from likely had a different directory. Or could it be because I am on a 64 bit version of windows 7, compared to the 32 bit version I was working on? (I really don't know just trying to think of some potential ideas).
Does anyone know of a solution? Should I simply uninstall and attempt to reinstall with minGW and SFML myself? Or is there a way to get around this without having to uninstall.
Thanks
Your compiler seem to be incompatible. If you've installed Qt with MinGW bundled together, you'll most likely have gotten MinGW 4.8.0 DW2 installed - it's the compiler for which a Qt package exists. On the other hand, if you've used the compiler that shipped with Code::Blocks you've most likely used the TDM 4.7.1 SJLJ compiler.
If you now try to use the same SFML libs or object files with from one compiler with another compiler, it won't work. Instead you'll have to option to either use the same compiler on both systems or compile everything freshly for both compilers.
is there any Binary Decision diagram (BDD) is available in windows.i tried to run cudd in vc++6.0..which is mention link
http://web.cecs.pdx.edu/~alanmi/research/soft/softPorts.htm
but it isn't working properly.i get compiler error while running a sample code
I compiled CUDD for Windows, but using MinGW not a Microsoft environment. My goal was that compiler since I use Dev-C as IDE.
I did a first try using Cygwin, but with no luck. The second try was with MSYS, an environment to run unix commands that come with MinGW for Windows. Note that CUDD uses a couple of POSIX libraries (such as ). Luckily they are used only in two secondary functions: CPU stats and a kind of fork that I didn't fully understood. Since I didn't need those, I simply commented the portion of code (in util/cpu_stats.c).
Then you only need to write a Makefile for MinGW in order to link the library!
If you need it, I can send to you the library already compiled.
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