It's worse still. Even on a Linux system with GNU tools, the slightest deviation from the author's system causes "interesting" failures. One recent one I encountered was glibc refusing to build with GNU binutils 2.20. The configure script was looking for a version of 2.1[3-9] and complained about it being too old otherwise. Then there is the whole cross-compiling issue.
The above notwithstanding, BSD people ought really think twice before opening their mouths. They have one of the most broken systems I know of, missing a huge number of standard (as in POSIX/SUS) features. Some of their system headers even refuse to compile without extra compiler flags.
Could you be more specific instead of just saying some vague statements without giving any information? What problems have you encountered on *BSD systems?
OK, off the top of my head (not all apply to all forks):
- The math library (libm) is incomplete.
- The 'nm' command has non-standard syntax.
- The 'od' command has non-standard syntax.
- System headers require -D_BSD_SOURCE or similar.
- System headers disobey standards in other ways.
- Not using -fPIC on OpenBSD gives unusable executables.
Is testing if "mkdir -p" is "thread-safe" practical? If you can trigger the failure in a configure test, fine, you know it's not. But if you don't manage to trigger the race condition after a few goes, what do you do?
You can't get ./configure to prove this platform's mkdir is safe so testing for versions of mkdir you know are safe having seen their source seems reasonable.
Grow up. C programs are ported painfully to each operating system. This is the reality programming in C. If the author does not support your system, he simply has not spent the time to port it. Proper autoconf tests isn't going to magically make software run on BSDs because the proper test won't be apparent until the author attempts to compile on BSDs. Does it suck? Yes. Has it ever been any different? No.
I suspect you're going to get downvoted for saying this, but I'm going to upvote you and give people a reason to think about this.
If someone goes through the time to program in C and release their source code for free, shouldn't we be thankful, rather than being upset at their autoconf tests they haphazardly threw together? I can't imagine how people can see these as being completely necessary.
I should point something out: this isn't really saying that autoconf isn't portable. It's saying that people need to quit writing autoconf stuff without realizing it might be run on a system other than linux.
As far as the linux-hate promoted by BSDers; I would like to try FreeBSD, and have been mildly interested since the late 1990s. Why don't you people make it reasonably available to people who don't personally know anyone who is running it and can't download it?
Who, me? NetBSD and OpenBSD are the worst. FreeBSD is a bit better, and Dragonfly is the least broken of the ones I've had to deal with. It's hard to keep track of all the BSDs, though, with the number of BSD developers and the number of BSD forks steadily converging.
It's hard to keep track of all the Linux distributions, though, with the number of Linux developers and the number of Linux distributions steadily converging.
OK, so maybe it's better now that Ubuntu has conquered all, but writing software on a BSD and then attempting to make it work on "Linux" is a nightmare. Every single distribution does something different, and it's a nightmare to work around. Whereas the BSDs tend to be very consistent.
Unless you can prove this, it's hearsay. Part of the reason why linux and BSD don't actually get POSIX certified is because they change so quickly that it wouldn't be practical. So it's difficult to get an idea of what system is most compatible with POSIX. And even if you did, it would be different by the next version.
OK, there are probably corner cases where Linux isn't quite compliant. However, in my day to day work, I encounter far more problems with BSD than with Linux. I don't know how I'd go about proving that to you.
Well that's true up until a point. But an OS is more than an API, it's also a collection of files and libraries within a directory structure. In my experience Linux distributions rarely agree on these minor points, and that is where the hassle lies in porting anything non-trivial.
The details where they differ are not standardised. If you stick to the standards, you will have no problems. The problem with BSD is that following standards is what gets you in trouble.
I spent an unreasonable amount of time porting software that is generally run on Linux and Mac OS X to RedHat (mostly because their fork of Linux appears to be a museum of obsolete libraries).
The BSD forks are often quite interesting in their goals. Some of the Linux ones are as well. There are so many more Linux forks than BSD forks though.
The above notwithstanding, BSD people ought really think twice before opening their mouths. They have one of the most broken systems I know of, missing a huge number of standard (as in POSIX/SUS) features. Some of their system headers even refuse to compile without extra compiler flags.