The configure scripts for xdm, lbxproxy, and xfs do not define the _XOPEN_SOURCE
macro on Hurd systems, causing these packages to fail to build.  The only time
they do define this macro is on Linux systems.

xdm uses crypt(), so it #includes <unistd.h>.  glibc requires _XOPEN_SOURCE to
be defined when that header file is included, if you wish to use crypt(3):
http://unixhelp.ed.ac.uk/CGI/man-cgi?crypt+3

lbxproxy manipulates the fds_bits member of variables of type fd_set, a
typedefed struct.  This member is normally named __fds_bits on glibc systems,
unless _XOPEN_SOURCE is defined.  This doesn't seem to be documented in
select(3); read the definition for fd_set in /usr/include/sys/select.h on a
glibc machine.

xfs does the same fds_bits manipulation as lbxproxy.

In all three programs, working around the problem by modifying the configure
scripts directly results in correct builds[1] for me.  Here's an example patch
for xdm:

--- configure.orig      2006-05-20 18:45:58.000000000 -0700
+++ configure   2006-06-20 20:00:11.000000000 -0700
@@ -21964,7 +21964,7 @@
 
 
 case $host_os in
-    linux*)
+    linux*|gnu*)
         OS_CFLAGS="-D_XOPEN_SOURCE"
        SU="su"
         ;;

A better solution, apart from of course modifying configure.ac, would be to base
the condition on whether the system uses glibc, rather than what the host kernel is.

I've only compiled the subset of X11R7.1 on The Hurd that I felt I needed to run
the various X clients.  This same problem could also be in the X server, or
elsewhere.

-----

1. Except for xdm, which I'm reporting other bugs on.  I have not yet tested
lbxproxy or xfs in any capacity.