I am trying to compile C code on a Mac (M2), with as target windows. I have tried this in the past on linux, with success, but there doesn't seem to be a straightforward way on Mac.
On the linux machine I was able to get a whole range of cross compilers from GNU, they had the system headers built in, so it was really really simple, something like
gcc-...-mingw main.c -o main.exe
would create a simple windows executable. From there it was as simple as moving the main.exe file to a usb drive or cloud to and transfer it to a windows machine to run it. Really simple!
For Mac I have found some resources about Clang, but you need to provide the system headers yourself, which I have no idea how to do. And there is more setting up, which I don't want to get into if there is a solution as simple as the one I just showed.
My question: What is the way to compile a C program on a Mac with the target system being windows, or even Linux?
Thanks for the help!
Visual Stdio Code has support for various C compilers native for M2. It isn’t a full IDE, simply a code editor with extensions.
You should be able to download the plugins/extensions you need via the GUI interface and let it manage the environment.
Related
I was just wondering, if there is a way, to compile my code, from my windows machine to other os, or do I have to setup everything for the compilation on VMs.
I have already changed up the code, so that it is possible to compile it on diffrent platforms, I'm just wondering if there is a way, to compile it for other operating systems in mingw, or in GNU. (If there is a way to do it in GNU, I'm fine with moving to linux, and compiling everything there)
This is exactly what is done when programming for Arduino, so yes it is possible.
But if you want to do it from Windows you may find it easier with LLVM/Clang than GCC, as it's not so easy to find cross compilers for many platforms that actually run on Windows.
It's a lot easier from Linux.
Or you can use CI tools like GitHub actions to build in the cloud.
I created an example project at https://github.com/brechtsanders/ci-test which uses GitHub actions (https://github.com/brechtsanders/ci-test/actions) to build on Ubuntu Linux, macOS and Windows.
You can use this project as the basis for a new cross-platform project.
I'm studying computer engineering and we have a class called operating systems where they lecture us about how OSes handle stuff etc. This week we were given a homework which requests us to code a shell that works on Linux. The problem is, they tought us literally nothing on how to code a shell so we are supposed to do some research and figure it out.
I found this guide online and it seemed perfect to me: link
Code, with explanations, what else could I ask for.
Now, I'm using a Windows PC and I use Dev-C++ IDE with GCC compiler. Can I code a shell that works on Linux with my current setup or do I have to install Linux? Are there any major differences between how shells run on these OSes?
If you want to write a shell for Linux, you want to target GNU/Linux which is basically POSIX with some extensions.
Dev-C++ by default uses MinGW GCC as its compiler, providing a Win32 API.
Win32 and POSIX are completely and fundamentally different. A shell written for one will not even slightly resemble the other.
Instead, you have several options:
Dev-C++ can optionally use Cygwin GCC, providing a more GNU/Linux-like experience on Windows. You need to take great care not to rely on any Cygwin-specific functionality like how it automatically translates pathnames and line terminators. You'll still need access to a Linux install to verify that it works.
Windows 10 lets you install WSL, a more modern Linux compatibility layer for Windows. Dev-C++ doesn't explicitly states it support it, so you may need to edit and compile separately, and may lose debugging functionality. You'll still need access to a Linux install to verify that it works.
Just run Linux in a VM. The only thing to care about is getting your shell working.
I would suggest saving yourself a ton of trouble right now and just download/install an Ubuntu image in VirtualBox.
I'm new to linux and have been learning gtk+ the past couple of days, and was wondering how you would go about compiling an application to run on windows instead of linux (ubuntu). I found this while doing a quick search but my knowledge of linux is non-existent at the moment so not sure how to proceed with the tutorial. Are there any alternative methods to do this?.
I've only compiled on Windows and used Cygwin to test 'nix versions (before going right into a 'nix OS and compiling), but looks like this might get you started.
Compiling in other OS does not make sense while you can't disribute your binary without testing it on the target platform.
Then why not to compile on the same platform?
I am in a big problem ..i have compiled my c files using linux make file in Linux OS.
I want to compile the same files in Windows using the same make file by command prompt. For that i have nmake utility and Cygwin utility too.
I have done that successfully with simple programs with simple make file ..
But it is not possible to compile when i was using the complex C files with complex make file.
I have changed the '/' in linux make file to '\' in windows? Anyother changes?
I want to know 'Is there any special make file formats in windows?'
also the difference between them..
I am really in need of that...
Unfortunately, nmake was only loosly inspired by make, and they didn't get many important things right. By far the easiest thing to do is to start by having the same flavor of make on both platforms.
On linux, Gnu make is the default and best option.
On Windows, there are several sources for Gnu make, with some quirks to choose among. Personally, I mostly use the native win32 build of Gnu make from the GnuWin32 project. You might want to poke around at the rest of the project's packages because some of the others will be useful to have as well.
Alternative sources are Cygwin and MinGW32/MSYS.
Cygwin is a credible attempt at providing a *nix compatibility environment on top of the Windows kernel. It consists of a DLL that exports a huge percentage of *nix (especially POSIX) system calls implemented via the Windows API. That DLL also has its own idea about disk mounts and prefers *nix-style path names. The DLL itself is licensed GPL (although a commercial-use license is available for a fee), and programs built in the Cygwin environment require it by default, so that can be a factor to consider. Another factor is that Cygwin is not friendly to normal Windows users, so development projects based on it usually end up difficult for non-unix users to deal with. For a cross-platform developer, however, Cygwin can be really useful as it gets you all of the usual suspect utility programs required by your Makefile, and it includes the MinGW32 native Windows targeted GCC as well as a GCC targeting the Cygwin environment.
MinGW32 is a porting project that did a really good job of porting the GCC compilers to run as native Windows executables. If used along with the header files they supply, it is possible to use nearly all of the Windows API via a C runtime DLL that ships with modern Windows installations.
MSYS is a lightweight fork of Cygwin that contains a minimal set of utilities (starting with a *nix shell) that are usually assumed to exist by a typical *nix Makefile. Unlike Cygwin, MSYS is configured such that the default target is the native Windows API.
What I'm trying to hint at here, and probably should just state flat out, is that your compatibility issues don't end with the dialect of make you use.
The Makefile language itself is highly dependent on the command shell available, and most serious project Makefiles end up using many of the *nix the core utilities such as cp and rm.
I would strongly recommend starting with the GnuWin32 build of make, and also installing MinGW32 and MSYS. It is then relatively easy to write a Makefile that works under both MSYS and linux, and needs only a small amount of platform-specific logic.
You should consider CMake for cross-platform make but your real problem is you shouldn't have to change the '/' to '\'. If you run under cygwin or msys (recommended) this should be handled for you.
NMake is a windows tool and will parse only windows-style paths, i.e. paths with drive letters and backslashes. Therefore you should use GNU Make installed with cygwin.
nmake should read your makefiles okay, the differences are generally between versions of make rather than OSs.
The big question is what your target platform actually is, are you trying to make this code operate in Windows natively or are you looking to run it under Cygwin?
Use gnumake on both platforms. I do. I haven't touched Visual C in years.
nmake got it's own format rather than windows itself, so makefile format is related to make tool rather than os. For simple things format is similar for g(nu)make and nmake, as people suggested before consider using gmake only.
I been looking into Cygwin/Mingw/lcc and I liked to be able to compile perl native C extensions on my windows(preferably under cygwin) and then run them on Solaris and HP unix without any further fuss, is this possible?
This all stems from my original perl cross-platform question here.
(This is a very old question, but missing some useful info --
I've personally done this for Solaris (SPARC & x86), AIX, HP-UX and Linux (x86, x64).)
Getting C++ cross-compiled is much harder than straight C.
HP-UX 32-bit PA-RISC is not supported because it uses SOM format instead of ELF and binutils doesn't (and likely won't ever) support SOM. In other words, you can only cross-compile 64-bit PA-RISC. (Requires PA-RISC 2.0 chip.)
I would go with mingw instead of cygwin, if you can. Cygwin introduces a lot of file permission headaches and cygwin1.dll dependencies that can be troublesome. If possible, however, build on linux. Everything will be much faster because all the tools and scripts you're running are designed for an environment where exec and stat are fast operations. Windows + NTFS is not that environment.
Start with the crosstools script, but be prepared to spend a lot of time on this.
Try with the very latest gcc/binutuils first, but if you can't overcome problems try dropping back to older packages. E.g. for Power3 (AIX) gcc 4.x series cross compiler generates bad code, 3.x is fine.
When copying native libs and headers make sure you are copying from the oldest machine you're likely to run on. Copying a new libc means your code won't run on any machine with an older libc.
When copying native libs and headers you probably want 'tar -h' to turn symlinks into actual files, also watch that on Solaris some requisite crt object files are buried in a cc directory, not under /usr/lib
Cross-compiler are very hard to setup and get working correctly.
Consider that (the people at) NetBSD have to put in a huge amount of work to get cross-compiling to work, and they're running the same OS, just different architectures.
You'd have to, at least, copy all the headers from the other OSs to Windows, and get a cross-compiler, linker etc for the target OS/architecture.
Also that may well not be possible - perl and shared libraries may be compiled with a native/non-gcc compiler which won't be available on Windows at all.
I agree with Douglas, that getting a cross compiler up and working is very hard to do. This is generally, your choice of last resort. If you are boot strapping, or making a binary for an embedded device, then often cross-compiling is your only option. You should be comfortable compiling your own gcc under Cygwin before considering cross compiling. To cross compile, you need to build a gcc to run under windows, but which will create binaries for your execution platform. Sample instructions for doing this can be found here.
Perhaps you are wanting to cross compile because you don't have root and/or can't compile on your target platform. For example, I had a hosting provider which ran Redhat Linux. I could run Perl CGI scripts, and associated modules, but I could not compile on the target machine, and an libraries I built had to exist in my own directory.
To solve this, I could have attempted to cross compile for my target platform, but instead, I decided to setup a similar host inside a VM on Windows. From within Cygwin, you can create a script which ssh's into your VM, copies your source, and does a full configure/build. The last step was to deploy the binary artifact onto my hosted system.
I've successfully had both Solaris 10 and Open Solaris running within a VM on Windows. Unfortunately, you might have a harder time running HPUX under a VM.
Why don't you have a read up on "Grand Unified Builder" (http://lilypond.org/gub/ and http://valentin.villenave.info/The-LilyPond-Report-11 (section #4))
I don't know how it works, but GUB allows the Lilypond developers to compile for about 11 platforms on a linux box.
Compile on Windows then use Wine to run them on any *nix. It works well most of the time.
No, this isn't possible at the binary level. There are so many differences at binary level between the various OSes and CPUs.
But what you can do is make the your C extensions source compatible so that it can compile to different platforms. C was designed as a "portable assembly language". As long as you stick with routines that are cross-platform, then they will usually work the same. You'll still need to test because there could be bugs that exists on particular platform.
This can't be done ... but is it that much of a hassle to recompile the code under Solaris or HP?