Discussion:
Compiling daemontools
Miles Wilton
2010-04-19 11:23:21 UTC
Permalink
Hi,

I had to alter src/error.h to get daemontools to compile on openSuSE:

Replaced the line

extern int errno;

with

#include <errno.h>

Thanks,

Miles.
Paul Theodoropoulos
2010-04-19 20:43:04 UTC
Permalink
most djbware requires this adjustment under linux variants. Some of the
djb installation pages make note of this, to wit

http://cr.yp.to/djbdns/install.html

but some don't, notably daemontools.
Post by Miles Wilton
Hi,
Replaced the line
extern int errno;
with
#include<errno.h>
Thanks,
Miles.
--
Paul Theodoropoulos
Dean Anderson
2010-04-19 21:55:29 UTC
Permalink
Yes. That is a obsolete method to link in errno. Multithreaded systems
need errno to be thread-specific, and so the interface to errno was
changed some time ago. There isn't an extern int errno anymore. The
anachronism 'extern errno' shouldn't link on any system, and doesn't on
most systems. But its a common thing found in older code.

<errno.h> will define errno to do the right thing for your thread model.

When I get a new distribution ready, I'll be sure to have this fixed.

--Dean
Post by Miles Wilton
Hi,
Replaced the line
extern int errno;
with
#include <errno.h>
Thanks,
Miles.
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 256 5494
Laurent Bercot
2010-04-20 19:03:17 UTC
Permalink
Post by Dean Anderson
Yes. That is a obsolete method to link in errno. Multithreaded systems
need errno to be thread-specific, and so the interface to errno was
changed some time ago. There isn't an extern int errno anymore. The
anachronism 'extern errno' shouldn't link on any system, and doesn't on
most systems. But its a common thing found in older code.
http://cr.yp.to/docs/unixport.html#errno

Single Unix v3 states that #include <errno.h> is the right way to
declare errno, so future software should indeed conform to that, but
still, maintaining "extern int errno" compatibility for single-threaded
programs wasn't hard and breaking it forcefully is a debatable design
decision from the glibc maintainers.

(If only that was their only debatable design decision. :))
--
Laurent
Dean Anderson
2010-04-21 23:36:10 UTC
Permalink
Laurent,

That sounds like a good point, but I'm not sure what version of Unix you
mean. System III? I don't think there was a written standard besides
man pages until the System V SVID came out, and I can't remember if that
was in the SVID. But I agree its always debatable to break old code,
and I've always admired the IBM MVS/zOS compatibility demands. But this
particular old code was probably a hazard. And Linux is relatively new
and old Unix compatibilty seems not to be a goal of Linux. If it were,
they could have taken the BSD4.3 net2 IP stack, the BSD4.4lite VFS
layer, etc and saved themselves a ton of work and many bugs. NFS still
doesn't work well on linux. Go figure.

Speaking of code and ancient unix, (if you're not interested, don't read
any further) I'm still hoping that SysV.2 and OSF/1 will get
open-sourced for a belated 40th aniversery. You all might know that BSD
4.3 code was opened by Novell/Caldera, and runs quite nicely on SIMH vax
simulator, as fast or faster than the real thing. But the the 4.3 distro
available now isn't quite pristine from CSRG tape, but appears it was
taken from a running system after being used/configured/etc. The Open
Group is probably going to make a pristine copy of 4.3BSD src available.
TOG also has a copy of Sys5.2 but for the vax only---someone deleted the
ATT 3b2 directories between 1991 and 1996 or so (I didn't work for TOG
those years--but it was there in 1991). OSF/1 is still encumbered by
SysV.2 (includes V.2 filesystem code) and probably can't be fully
released until Novell/Caldera gives a green light on SysV.2. But given
that 4.3BSD is released, I'd think there should be little problem with
releasing SysV.2 if someone asks nicely...

--Dean
Post by Laurent Bercot
Post by Dean Anderson
Yes. That is a obsolete method to link in errno. Multithreaded systems
need errno to be thread-specific, and so the interface to errno was
changed some time ago. There isn't an extern int errno anymore. The
anachronism 'extern errno' shouldn't link on any system, and doesn't on
most systems. But its a common thing found in older code.
http://cr.yp.to/docs/unixport.html#errno
Single Unix v3 states that #include <errno.h> is the right way to
declare errno, so future software should indeed conform to that, but
still, maintaining "extern int errno" compatibility for single-threaded
programs wasn't hard and breaking it forcefully is a debatable design
decision from the glibc maintainers.
(If only that was their only debatable design decision. :))
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 256 5494
Peter Pentchev
2010-04-22 06:48:33 UTC
Permalink
Post by Dean Anderson
Laurent,
That sounds like a good point, but I'm not sure what version of Unix you
mean. System III?
[snip]
Post by Dean Anderson
Single Unix v3...
Erm, I believe that he's referring to the slightly more modern
Single Unix Specification version 3, available from The Open Group -
you know, the guys that actually discuss and update the POSIX standards.

G'luck,
Peter
--
Peter Pentchev ***@ringlet.net ***@space.bg ***@FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
"yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation.
Loading...