> On Fri, Jan 28, 2000 at 09:36:30AM -0800, Brent Fulgham wrote: > > Errno seems problematic on the Hurd for some reason. I've seen > > a few cases where the header has needed to be added to source > > files for a clean compile, whereas it was not needed on other > > environments (such as Linux). > > Of course, using errno without including <errno.h> is the > Wrong Thing (tm). > > There is a good reason, too: > > /* Declare the `errno' variable, unless it's defined as a macro by > bits/errno.h. This is the case in GNU, where it is a per-thread > variable. This redeclaration using the macro still works, but it > will be a function declaration without a prototype and may trigger > a -Wstrict-prototypes warning. */ > #ifndef errno > extern int errno; > #endif > > and in bits/errno.h: > > /* errno is a per-thread variable. */ > #include <hurd/threadvar.h> > #define errno (*__hurd_errno_location ()) > #define __set_errno(val) errno = (val) > > So it is a macro and not an extern int variable, which is why > the linker can't see it. > Ahh -- this makes a lot of sense now. So we should probably file bugs upstream against software that makes use of errno without including the errno header file in a particular module/source file. I think there's a lot of stuff out there that relies on the belief that it's an `extern int`, which is (as we now know) not always the case.
-Brent
