
Autoconf and portable programs: the joke - bensummers
http://marc.info/?l=openbsd-ports&m=126805847322995&w=2
======
mansr
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.

~~~
l0stman
Could you be more specific instead of just saying some vague statements
without giving any information? What problems have you encountered on *BSD
systems?

~~~
mansr
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.

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

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

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

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

~~~
tjarratt
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.

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

------
billswift
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?

~~~
duncanj
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...](http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors.html)

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

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

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

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

~~~
astine
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.

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

~~~
mansr
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.

~~~
bensummers
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.

~~~
mansr
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.

~~~
j_baker
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.

~~~
mansr
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.

~~~
j_baker
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?

------
iambvk
i smell something burning...

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

