Why is compiling on Windows such a nightmare?
I do everything on Windows - my personal stuff, my school stuff, my development, etc. I have very few complaints with the OS. But something has always bothered me: compiling open source software on Windows is a nightmare. Over the years I've tried many times to compile various open source projects, and I always see the same trend: the larger the project is, the less support it has for Windows.
GCC has no support for Windows, meaning you have to use MinGW or Cygwin to use it. People laugh at you if you ask them how to compile GCC on Windows. I understand they don't like closed platforms like Windows, but that's no reason to screw over your users.
Git has no support for windows, meaning you have to use one of the many git-for-windows projects out there. It doesn't even have Windows symlink support by default unless you specifically enable it. I understand that git's file system is modeled after *nix, but...wait, no, actually I don't understand why such a non-portable decision was made.
Many open source C++ projects I find on GitHub are only well tested on *nix because that's all the developers seem to use or have access to. I even see blatant portability problems in the code that could easily be fixed. Sometimes it's even as bad as unconditionally including one or more *nix-only headers and then claiming the project "should work" on Windows.
I also see lots of jokes about open source and Windows. People tell me compiling on *nix is a breeze and that if you want to compile on Windows you're basically screwed.
Over and over I run into the same portability issues when trying to compile stuff on Windows. It's basically impossible for me to accomplish anything unless I use pre-compiled binaries that someone else went through the trouble of making for me. Generally the way these binaries are created is by cross-compiling from *nix to Windows...clearly it is unthinkable to both compile on Windows and target Windows at the same time.
What's the deal? Why is this even a thing in the first place? Is it really that hard to write portable code and use portable libraries? Is it just a historical hold-over and things are getting better now? I want to know the cause of my pain.
I know the opposite problem exists for some software (only having good Windows support and poor *nix support), and if I primarily used *nix I might be on the other side of the same boat, but so far everything I've seen makes the poor Windows support out to be much more common than poor *nix support. It just seems a weird imbalance to me.
I need to know this isn't just me.
(I have my own reasons for not using *nix that I don't think are relevant to discussion here.)
GCC has no support for Windows, meaning you have to use MinGW or Cygwin to use it. People laugh at you if you ask them how to compile GCC on Windows. I understand they don't like closed platforms like Windows, but that's no reason to screw over your users.
Git has no support for windows, meaning you have to use one of the many git-for-windows projects out there. It doesn't even have Windows symlink support by default unless you specifically enable it. I understand that git's file system is modeled after *nix, but...wait, no, actually I don't understand why such a non-portable decision was made.
Many open source C++ projects I find on GitHub are only well tested on *nix because that's all the developers seem to use or have access to. I even see blatant portability problems in the code that could easily be fixed. Sometimes it's even as bad as unconditionally including one or more *nix-only headers and then claiming the project "should work" on Windows.
I also see lots of jokes about open source and Windows. People tell me compiling on *nix is a breeze and that if you want to compile on Windows you're basically screwed.
Over and over I run into the same portability issues when trying to compile stuff on Windows. It's basically impossible for me to accomplish anything unless I use pre-compiled binaries that someone else went through the trouble of making for me. Generally the way these binaries are created is by cross-compiling from *nix to Windows...clearly it is unthinkable to both compile on Windows and target Windows at the same time.
What's the deal? Why is this even a thing in the first place? Is it really that hard to write portable code and use portable libraries? Is it just a historical hold-over and things are getting better now? I want to know the cause of my pain.
I know the opposite problem exists for some software (only having good Windows support and poor *nix support), and if I primarily used *nix I might be on the other side of the same boat, but so far everything I've seen makes the poor Windows support out to be much more common than poor *nix support. It just seems a weird imbalance to me.
I need to know this isn't just me.
(I have my own reasons for not using *nix that I don't think are relevant to discussion here.)
Last edited on
I've always wondered the same thing. It's made me mostly dread doing development on Windows, with the exception of Android and C# projects. I've never given much thought to it besides, as you said, being a pain to build anything on Windows. I've always attributed that to not great command line tools and NTFS just being annoying to work with, but that doesn't address the issue of code not being portable.
One issue that I just thought, it seems a lot of CI systems don't provide Windows systems to build on, at least for free. This makes sense, as that's money to whoever runs the CI system. It's easier and cheaper to build out a bunch of *nix boxes than it is for Windows boxes.
One issue that I just thought, it seems a lot of CI systems don't provide Windows systems to build on, at least for free. This makes sense, as that's money to whoever runs the CI system. It's easier and cheaper to build out a bunch of *nix boxes than it is for Windows boxes.
| ResidentBiscuit wrote: |
|---|
| One issue that I just thought, it seems a lot of CI systems don't provide Windows systems to build on, at least for free. This makes sense, as that's money to whoever runs the CI system. It's easier and cheaper to build out a bunch of *nix boxes than it is for Windows boxes. |
Besides that time I tried to link Cairo statically and woke up three days later naked in a field somewhere with someone else's blood on my face, I haven't had that many issues compiling libraries in Windows. Most of the time it's enough to just put all the files in a VS project, provide a custom config.h, and perhaps remove some includes for POSIX headers or provide your own dummy header with a simple implementation. Often libraries include a particular header everywhere and just use some dumb function that does practically nothing.
One exception to the above is this: a few years ago it was painful to build FFmpeg so it could be used with MSVC, although it was easy enough to build with MinGW. I ended up making a Linux VM to produce the binaries, following the instructions of someone who was building nightlies and making them available somewhere. The problem was that FFmpeg used C99 features not implemented in MSVC, besides using GCC inline Assembly. My understanding is that this has changed since then and now it build just fine with MSVC.
I haven't needed to build many complete programs besides Bison and a few other small things, though.
One exception to the above is this: a few years ago it was painful to build FFmpeg so it could be used with MSVC, although it was easy enough to build with MinGW. I ended up making a Linux VM to produce the binaries, following the instructions of someone who was building nightlies and making them available somewhere. The problem was that FFmpeg used C99 features not implemented in MSVC, besides using GCC inline Assembly. My understanding is that this has changed since then and now it build just fine with MSVC.
I haven't needed to build many complete programs besides Bison and a few other small things, though.
I've been struggling with this very issue recently.
I think mostly, it's just because the sort of people who tend to be enthusiastic about open-source software tend to be very sniffy about Windows. They want to work on Linux, and are almost ideologically opposed to supporting a commercial operating system. They'll pay lip-service to it, but often they'll just ignore it, assuming that one of those nasty Windows enthusiasts will come along and make a Windows build of it - which, of course, will be unsupported, un-maintained, and often only works for a subset of configurations.
With the rise of CMake, it's become a little easier - Google Protobuf was relatively hassle-free, because the latest beta release has switched to using CMake. But it's still frustrating.
There's nothing fundamentally more difficult about developing software on Windows. It's just that the open-source community doesn't like to.
I think mostly, it's just because the sort of people who tend to be enthusiastic about open-source software tend to be very sniffy about Windows. They want to work on Linux, and are almost ideologically opposed to supporting a commercial operating system. They'll pay lip-service to it, but often they'll just ignore it, assuming that one of those nasty Windows enthusiasts will come along and make a Windows build of it - which, of course, will be unsupported, un-maintained, and often only works for a subset of configurations.
With the rise of CMake, it's become a little easier - Google Protobuf was relatively hassle-free, because the latest beta release has switched to using CMake. But it's still frustrating.
There's nothing fundamentally more difficult about developing software on Windows. It's just that the open-source community doesn't like to.
| helios wrote: |
|---|
| Most of the time it's enough to just put all the files in a VS project, provide a custom config.h, and perhaps remove some includes for POSIX headers or provide your own dummy header with a simple implementation. |
CMake is really a lifesaver - everything I have tried to compile with CMake has been a breeze. It's the huge number of projects that don't use CMake that I have a hard time with. Thankfully more and more people are switching to it. (And, also thankfully, the CMake 3 documentation is much improved - it's no longer all on a single huge page)
Last edited on
If that's what you call a nightmare, you should try what I said about compiling Cairo statically. You'll have lots of fun.
There's generally no information. You just dump everything in and take stuff out until both the compiler and linker are happy. I call it "easy" if you can do this and have a binary within an hour.
| There's often very little information on how to do that correctly. |
| helios wrote: |
|---|
| There's generally no information. You just dump everything in and take stuff out until both the compiler and linker are happy. I call it "easy" if you can do this and have a binary within an hour. |
This has been my experience to. It's helpful to know your compiler and I make mistakes so often in my own code that I can recognize the oddball, or just plain wrong, compiler errors pretty quickly. The most frustrating common issue is having to do a find and replace all to get cl.exe to stop whining about some "unsafe" function or another; but that isn't even necessary.
The worst project for me was iPXE. I got the entire project to compile except for the asm files which used some buffer swap assembly command that neither MSVC's or MingW's tool chain had translated for Windows yet. The part that is really frustrating is that I'm certain that if they would just pre-compile the Asm files and link them to the project instead of trying to compile everything from scratch (seriously, it's assembly, what's the point?) that it would be trivial to get working for Windows. I lost my motivation though after switching from FOG to WDS for my imaging solution. After comparing the two there is no way that I'm going back.
Here's a case where the developer of the project basically ran into all the same issues as me:
https://github.com/mosra/magnum/issues/109
https://github.com/mosra/magnum/issues/109
| Mosra wrote: |
|---|
| Then I got mad at this pathetic platform which doesn't have a single compiler that does what one would expect. |
| helios wrote: |
|---|
| Most of the time it's enough to just put all the files in a VS project, provide a custom config.h, and perhaps remove some includes for POSIX headers or provide your own dummy header with a simple implementation. |
Yeah, this is not ever a good situation.
| Mosra wrote: |
|---|
| Fortunately there are those tiny graphs that show which files the people are interested in and which not, so I downloaded the file that had the bluest graph, |
http://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/
If your code doesn't build on the main compilers for your target platforms then it's your code that's broken, not the compilers. It's nice to pretend that calling a compiler is the same as passing your program through an mathematically proven implementation of the standard, but in reality it just isn't so.
For example, just a few months ago I ran into a bug in MSVC's std::lower_bound() that caused rejection of slightly oddly typed code. 3.x versions of MinGW runtime or compiler (I forget which) had a bug where trivially correct code would crash when performing certain basic operations on streams in a certain way.
Bugs are just a fact of life and are equally likely across platforms. Pretending they don't exist serves no purpose.
If your code doesn't build on the main compilers for your target platforms then it's your code that's broken, not the compilers. It's nice to pretend that calling a compiler is the same as passing your program through an mathematically proven implementation of the standard, but in reality it just isn't so.
For example, just a few months ago I ran into a bug in MSVC's std::lower_bound() that caused rejection of slightly oddly typed code. 3.x versions of MinGW runtime or compiler (I forget which) had a bug where trivially correct code would crash when performing certain basic operations on streams in a certain way.
Bugs are just a fact of life and are equally likely across platforms. Pretending they don't exist serves no purpose.
@helios: I guess the question is, why do the compiler bugs happen more often on Windows? (Let's ignore Visual Studio, it's obvious they were completely unprepared for C99 and C++11)
Last edited on
I literally linked to a case where the same version of the same compiler worked on *nix and not on Windows on two separate occasions? But yes, it was a bad assumption to make, sorry.
That's not enough to conclude anything.
First, n=1 is a rather small statistical sample isn't it?
Second, what if I complained that BSD is shitty because my code works flawlessly on Windows but not on BSD, and later we find out that I was doing std::ifstream("\\foo.txt")? We don't know what causes the bug, so the fact that it happens on Windows and not on Linux doesn't tell us anything. We don't even know if the particular guilty code is shared by both implementations. We also don't know whether the bug is actually a bug in both version and simply doesn't trigger in one because it doesn't violate some assumption on Linux.
There's simply not enough information.
First, n=1 is a rather small statistical sample isn't it?
Second, what if I complained that BSD is shitty because my code works flawlessly on Windows but not on BSD, and later we find out that I was doing std::ifstream("\\foo.txt")? We don't know what causes the bug, so the fact that it happens on Windows and not on Linux doesn't tell us anything. We don't even know if the particular guilty code is shared by both implementations. We also don't know whether the bug is actually a bug in both version and simply doesn't trigger in one because it doesn't violate some assumption on Linux.
There's simply not enough information.
Nobody (besides mosra) is saying the compiler is "shitty". We know for a fact the code was legal and portable, and that the code successfully compiled in a later version of the compiler. For me, that is more than enough information to say that it was, in fact, a bug.
Whether it's a bug is not in dispute. What's disputed is whether the presence of this bug alone, with no additional information, is enough to interpret it as evidence for the statement "compiler bugs happen more often on Windows".
I already said that was a bad assumption and apologized for it though? Sorry if you misunderstood.
Last edited on