Comment 5 for bug 1198739

Probably :)

On Jul 9, 2013, at 3:07 AM, Pino Toscano <email address hidden> wrote:

>> BTW many systems will set _GNU_.
>
> No, __GNU__ is set only on the Hurd.
> I think you are confusing it with __GNUC__, which is set by the GCC compiler (and not by OSes).
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1198739
>
> Title:
> Fails to build on GNU/Hurd
>
> Status in Gearman Server and Client Libraries:
> New
>
> Bug description:
> gearmand 1.1.8 does not compile on GNU/Hurd. Also, there are failures
> when running the test suite.
>
> The attached patch fixes the following issues:
>
> * libtest/timer.cc
> The code in the __MACH__ blocks is specific to Mac OS X; since GNU/Hurd runs on a Mach-based microkernel (gnumach), __MACH__ is defined by the compiler, leading to compile issues. The solution is just changing the checked symbol (__APPLE__) so it is really used only on Mac OS X.
>
> * libhostile/t/pipe.c
> pipe(NULL) returns EINVAL as errno on Hurd (which seems legit), so extend the check to allow EINVAL too.
>
> * libtest/unittest.cc
> The Hurd implementation of posix_spawn in glibc fails straight away when the filename does not exist, i.e. what happens in application_doesnotexist_BINARY. Thus, fix the expected return value to be INVALID_POSIX_SPAWN.
>
> There are other failures though, some of which seem due to
> SOCK_CLOEXEC and SOCK_NONBLOCK defined but not supported (yet) for
> socket (but they are in accept4, for example). So even if not all the
> issues are fixed, the provided ones could be checked in anyway, and at
> least allow to compile gearmand on GNU/Hurd and reduce the failures.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gearmand/+bug/1198739/+subscriptions