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.
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.
Ideally, I want to compile our QT-based apps, which also link other third-party libraries, on 64-bit Linux using GCC, but for a 64-bit Windows target. Again ideally, I want the result to run on 64-bit Windows without any additional runtime support, just as if we had compiled the same source code in Visual Studio. Is this possible with MinGW-w64?
I have successfully used MinGW-w64 to compile simple apps with GCC on Windows. I'm not sure how much of the MinGW-w64 installation is runtime support for executables as opposed to support for the GCC compilation environment. I did attempt to run a WinGW-w64 hello world executable on an installation of Windows without MinGW-w64, but had missing dll errors. This tells me that some runtime support was necessary, but I would like to know more precisely what is required.
If you don't want to install Windows, I think the best way is using a Virtual Machine. That's because even if the source code compiles for Windows, how could it be verified to run? You will need a real target environment to finally test your application.
From a complexity point of view, I think setting up a Windows machine (VM or not) and the necessary environment for Qt is a whole lot simpler than cross compiling bug hunting afterwards.
You can install Qt on the installed Windows, copy your project there, compile it and see the results in the real environment. This way you can cope with the minor differences when porting from one OS to another easily.
Nothing stops you from developing on Linux. You can do the entire development on Linux and just test the code on the prepared Windows by compiling and running. Sending the code to the Windows environment is simple by using git. The development process can be like :
Make a repository of your application, clone the repository both on Linux and Windows
Do the Major development on Linux and push
Pull on Windows from time to time, compile, test and make minor fixes and then push
I have developed some code under Unix using Cgwin, Linux and HP-UX. Since I don't want to start from scratch when doing some Windows stuff, I wanted to compile the code with Visual Studio 2008. Of course I'm aware that I have to do some adaptions, regarding system specific functionality like using fcntl. What I didn not expect though, was that there seem to be also problems using standard functions like snprintf etc.
snprintf and Visual Studio 2010 or
Error 4 error C3861: 'snprintf': identifier not found
Since there are also many other problems, I was considering using MingW. As far as I understood, MingW is a native Windows compiler right? So I still would have to port the systerm specific stuff, but I would like to know, if the move to MingW would give me any benefit by reducing the number of compatibillity issues.
I'm aware that this might be regarded as opnion based, but I don't want to compare MingW vs. MSVC, I just would like to know if the switch would reduce the porting issues, or if it is as waste of time and just as well stick to MSVC. I have ported code before, but always from Windows to Unix, which seems to have been much easier then the other way around.
As far as I understood, MingW is a native Windows compiler right?
If by native you meant Windows as a target OS, then yes. But if you were thinking about the building host - If you want so. MinGW is a GCC port, and can be built for Linux as well. Latest Ubuntu has both x32 and x64 versions of MinGW, for example.
I would like to know, if the move to MingW would give me any benefit
by reducing the number of compatibillity issues.
Definitely yes. Using GCC port means you will need to solve only OS-dependent issues, and skip compiler and Microsoft library differences.
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
I am trying to modify a current MFC application running on Windows NT4 to use boost libraries for ethernet communcications (originally, it used CommX for serial) and general increased performance, effieciency, and clarity of code.
I started out modifying it in VS2010, but I found that I was unable to produce a valid NT4 app with VS2010. I googled the issue and found that VS2005 was the last version able to create an NT4 app. I got everything to compile in VS2005, but found that I had to change certain #define statements in stdafx.h in order to get the app to run on NT4. However, even after doing that, when I execute the program on NT4, it immediately quits with no error. It doesn't show anything. I even checked the Task Manager processes while executing it. It is like it never executed at all.
I got desperate and tried compiling the app in VS2003, but I got so many errors that I gave that up.
My last attempt was VC6, but again, I got 262 errors and started wondering whether it was even possible for boost to run in VB6 or on an NT4 machine.
Is it even possible to compile and run an MFC app with boost libraries on an NT4 machine? If so, which environment/compiler do I need and how do I configure it to work correctly?
This is a very tight-schedule project, so any (prompt) help would be very appreciated! Thank you!
If you're trying to use VC6 to compile code that uses Boost, you may need an older version of Boost. Try 1.34.1.
You might try using STLport as the standard library implementation instead of the built-in STL that comes with VC6. I'm using boost 1.32 and STLport 4.6.2 successfully in VC6 with an MFC project. I haven't tried moving up to newer versions of boost or STLport, but STLport might be enough to get you going.