I want to use Linux to compile code and create a .exe that can be used on Windows. The reasons being that I have been having difficulty getting CGAL to work with MinGW on Windows 7 and this proved trivial using Ubuntu on VirtualBox.
A three year old question here advises the download and install of a prebuilt compiler from the MinGW(-w64) project itself. A more recent answer (2 years old) advises the use of http://mxe.cc/. Have there been more recent development for cross compiling fortran programs in Linux for use in Windows or are the answers given previously still the most up to date?
Related
I'm going to teach students to use SFML with C++, and I'm afraid the school doesn't have visual studio C++ installed, or will be a bit heavy to use for those students.
I want to have a plan B and have the option of a simple makefile that I can build on windows with SFML.
https://www.sfml-dev.org/download/sfml/2.5.1/ this page offers binaries compiled with different, specific versions of mingw with their respective mingw package links, unfortunately mingw doesn't include an unix terminal, like the one included with git-bash, so I can run a makefile.
What are the steps required to have a problem unix terminal, running in windows, minsys, msys2 or not, that can work well with those mingw packages? I have trouble finding help or proper instructions.
You want https://www.msys2.org/
It provides bash terminal and already contains mingw compiler. Perhaps it even has SFML packages already.
Interesting delema.
Trying to compile Qt program where Qt is build from source on 18.04 64-bit and run it on 14.04. The interesting part is trying to identify which libraries I need this time. The C++ ABI has changed.
Looking to see if anyone else has done this recently? Which libraries do I have to bring along? Yes, I know about ldd and readelf and have spent days trying this in various VMs. The problem is once you start bringing the C++ stuff over (because the ABI has changed yet again) you get to a point where your VM won't reboot.
Please don't suggest snappy, flatpak or one of those other new "container" solutions. Already wasted 3+ days on snappy. It's architecture specific and only supports building on 14.04 when it comes to Qt, at least the deployqt tool to make an AppImage does.
Did this years ago with this very program. Built a debian which would install on both 64-bit and 32-bit for every version from 12.04 to 15.04 including the short lived .10 and odd year versions.
I tried compiling QT with C++11 standard, but, it will no longer compile with that standard.
The incompatible ABI is the real killer.
It is more than one program so the hack of a shell script using LD_LIBRARY_PATH would bring considerable difficulty.
Appreciate insights.
Thank you.
Please always develop applications on the oldest distribution you still want your application to run on. For example, if you want your application to run on all currently still-supported versions of Ubuntu, then develop your application on Ubuntu 14.04 and do not install any newer compilers or libraries than what it comes with.
This is how "backward compatibility" works.
This question already has answers here:
Deploying Yesod to Heroku, can't build statically
(4 answers)
Closed 6 years ago.
I am getting this error while I am running the code in GLIBC version 2.12, which was compiled in 2.19.What is the standard solution to this problem, so that the code can run in all versions.Upgrading the target machine to 2.19 is not an option because this software is supposed to run in at least 5000 machines.Dow grading the development machine to 2.12 is also not a proper solution. Because 2.19 is just one example. The 5000 target machines can have any version.What is the standard solution for this ? Anyway of static compilation ? I mean bundling the entire GLIBC with the code .
The easiest solution is to simply create a "build server" which you use for your production builds, and keep this server on the oldest version of everything you need to support, including glibc.
This can be done using a VM inside your development server if you don't want to use a physical machine.
Bbinaries compiled against glibc should be forward-compatible; the binaries you compiled against glibc 2.19 were using an API version that appeared in 2.14. If instead you compile against 2.12 it should work at runtime with Glibc 2.19 as well.
In Python-land, they're now offering prebuilt Linux C extensions that are built on Centos 5.11 Docker images; The PEP 0513 explains details. They seems to work pretty well there. Centos 5.11 seems to have glibc 2.5; Centos 6 has glibc 2.12. I am using these prebuilt .sos on Ubuntu 14.04 and 15.10 myself without any problems.
There is also a very hackish solution, by placing the required libc.so (2.19) file in a specific directory (just copy it over), creating a runner script, where you set the LD_LIBRARY_PATH to have the specific directory and then you run the executable. The system should pick up the libc.so from the specific directory before the one provided by the system, so it should work.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I downloaded the MATLAB code from here http://cazencott.info/dotclear/public/code/scones.zip. When I run 'demo', it says "Undefined function 'maxflowmex' for input arguments of type 'double'". In fact there is only a c++ file "maxflowmex.cpp" in the folder (already added to path). Whether it needs a "maxflowmex.m" instead of "maxflowmex.cpp" to run properly? Or some other methods to call "maxflowmex.cpp"? Or I need to compile something?
I just took a look at the zip file. There are MEX wrappers in the maxflow directory that are written where MATLAB calls these functions which are written in C, but are runnable in MATLAB. These MEX wrappers need to be compiled using a compiler that is compatible for your operating system before you run them.
However, there are pre-compiled binaries, but I only see 64-bit binaries for Linux and Mac OS and I don't see Windows binaries. Because you can't run them, you are most likely running a 32-bit operating system or Windows. I suspect you are running either Windows or 32-bit Linux, as Mac OS by default ships out as 64-bit.
There is a make.m script that you need to run so that you can compile the maxflow library for your machine. Once you compile the library, running demo.m should be successful.
Before you do that, you need to make sure you set up mex by doing mex -setup in the command window, then choose the right compiler. Once you do this, run make.m that's inside the maxflow directory.
If you don't have a compiler, if you're using Linux, doing an apt-get on the gcc packages should be good enough, so:
sudo apt-get update
sudo apt-get install gcc-4.6-base g++-4.6 cpp-4.6 libgomp1 libquadmath0 libc6-dev
If you are using Windows, then the supported compiler that you need will depend on what version of MATLAB you are using. I'm assuming you are using the latest one, and so downloading the latest version of Visual Studio Express as well as the SDK should be sufficient.
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
http://www.microsoft.com/en-us/download/details.aspx?id=40758
I have a Windows 7 laptop with an Ubuntu 12.04 installation on the same machine.
I am trying to compile a program from source (VowPal Wabbit). I tried using Cygwin but had no luck getting it to work. I ended up installing Ubuntu 12.04 to get access to get a functioning compiler.
It worked on the Ubuntu side but I am curious if there is a way to bring the compiled files over to Windows as that's where I actually do most of my work. More specifically, will programs compiled in Ubuntu function on a Windows machine?
Any suggestions?
You should check out MinGW:
MinGW, a contraction of "Minimalist GNU for Windows", is a minimalist
development environment for native Microsoft Windows applications.
I realize it is almost a year later. Credit Chris Quirk, Nick Nussbaum and others, current versions of vowpal wabbit (7.x) should build and work fine on Windows.
This reference should provide all the necessary details.
Edit: 2017-07-10:
I should also note: the library and basic train and test from files functionality has been working on Windows for a while. However, not all the functionality supported in a native Linux environment is available on Windows. In particular, the --daemon option, network related features like spanning-tree (under the cluster directory), and some of the utilities under the util directory have not been fully ported and/or tested on Windows. vw developers welcome pull-requests from Windows users.