30 ms·
Autoconf and portable programs: the joke
- mansr 17y agoIt'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.
- l0stman 17y agoCould you be more specific instead of just saying some vague statements without giving any information? What problems have you encountered on *BSD systems?
- mansr 17y agoOK, 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.
- tedunangst 17y agoSystem headers should only require BSD_SOURCE if you've asked for strict ansi mode, just like gnu headers require GNU_SOURCE.
- mansr 17y agoThe glibc headers work perfectly in strict C99 mode. The BSD headers do not.
- jvdh 17y agoFreeBSD is actively trying to get to POSIX and C99 conformance, see http://www.freebsd.org/projects/c99/index.html http://www.freebsd.org/projects/c99/index.html
- vext01 17y agoI'm sorry? Which BSD system is that you are describing?
- mansr 17y agoWho, 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.
- bensummers 17y agoIt'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.
- mansr 17y agoPOSIX compliance is much better in Linux than in BSD. End of story. If you stick to standard POSIX features, your code will work without change on any modern Linux distribution.
- j_baker 17y agoUnless 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.
- mansr 17y agoOK, 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.
- smackfu 17y agoWho is writing these tests? Are they standardized, or does each maintainer have to write their own?
- ralph 17y agoIs 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.
- bobbyi 17y agoDon't most people on BSD also use GNU tar, coreutils, etc?
- astine 17y agoNo, BSD has it's own toolstack. It's marketed as a complete system (FreeBSD anyway.) That, in theory, is one of it's draws.
- vier 17y agoGrow 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.
- tjarratt 17y agoI 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.
- j_baker 17y agoI 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.
- iambvk 17y agoi smell something burning...
- billswift 17y agoESR has a new post up "Autotools Must Die" http://esr.ibiblio.org/?p=1877 http://esr.ibiblio.org/?p=1877 . His main suggestion is moving to something else - he suggests scons http://www.scons.org/ http://www.scons.org/ . 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?
- duncanj 17y agoI hate to google things for people, but is none of these vendors good for you? http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mi...
- wendroid 17y agoYou think it's bad on BSD, try porting stuff to Plan9!