Autoconf and portable programs: the joke | Hacker News Reader

Autoconf and portable programs: the joke

marc.info

70 pointsbensummers31 comments

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?

FreeBSD is actively trying to get to POSIX and C99 conformance, see http://www.freebsd.org/projects/c99/index.html

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.

System headers should only require BSD_SOURCE if you've asked for strict ansi mode, just like gnu headers require GNU_SOURCE.

The glibc headers work perfectly in strict C99 mode. The BSD headers do not.

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.

ESR has a new post up "Autotools Must Die" http://esr.ibiblio.org/?p=1877 . His main suggestion is moving to something else - he suggests scons 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?

I 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/mi...

Who is writing these tests? Are they standardized, or does each maintainer have to write their own?

each software package that uses autoconf prior to compiling writes their own set of tests.

There are standard ones you can pick up for many things, e.g. http://ac-archive.sourceforge.net/

Don't most people on BSD also use GNU tar, coreutils, etc?

No, BSD has it's own toolstack. It's marketed as a complete system (FreeBSD anyway.) That, in theory, is one of it's draws.

I'm sorry? Which BSD system is that you are describing?

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.

True, but the most relevant part for POSIX is always GNU/Linux, which is always the same in each of the Linux distributions.

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.

POSIX 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.

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.

I don't doubt that you do encounter more problems with BSD than Linux. But does everyone who works with the two encounter more problems?

Too bad nobody does this...

Quick example:

http://shootout.alioth.debian.org/gp4/program.php?test=threa...

Can you spot the non-compliant behavior in this? It actually relies on undefined behavior in the POSIX spec to work on linux!

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.

i smell something burning...

You think it's bad on BSD, try porting stuff to Plan9!

Reply on news.ycombinator.com