Fails to build on GNU/Hurd

Bug #1198739 reported by Pino Toscano
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Gearman
Incomplete
Wishlist
Brian Aker

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.

Revision history for this message
Pino Toscano (pinotree) wrote :
Revision history for this message
Brian Aker (brianaker) wrote :

Thanks!

I'll see if it is simple to add a GNU/Hurd system to check for regressions.

Changed in gearmand:
assignee: nobody → Brian Aker (brianaker)
importance: Undecided → Low
Revision history for this message
Brian Aker (brianaker) wrote :

BTW many systems will set _GNU_. Is there a more hurd specific value that could be used?

Revision history for this message
Pino Toscano (pinotree) 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).

Revision history for this message
Brian Aker (brianaker) wrote : Re: [Bug 1198739] Fails to build on GNU/Hurd

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

Revision history for this message
Brian Aker (brianaker) wrote :

I am having zero luck getting a work GNU/Hurd distribution.

This makes it very problematic to support this platform.

Changed in gearmand:
importance: Low → Wishlist
Revision history for this message
Pino Toscano (pinotree) wrote :

> I am having zero luck getting a work GNU/Hurd distribution.

Unless you say which issues you faced, there is hardly anything I can do to help you...

> This makes it very problematic to support this platform.

In general we could help with porting, in case issues arise, either pointing out problems or (as I did) sending patches when possible.
Even if the current patch does not fixes all the issues exposed by running the test suite, at least allows the build as starting point in debugging the rest of the failures.

Revision history for this message
Brian Aker (brianaker) wrote : Re: [Bug 1198739] Re: Fails to build on GNU/Hurd

Does anyone have a VM? Either one I can use with Parallels or Open Stack (QCOW2 format)?

On Aug 11, 2013, at 7:33 AM, Pino Toscano <email address hidden> wrote:

>> I am having zero luck getting a work GNU/Hurd distribution.
>
> Unless you say which issues you faced, there is hardly anything I can do
> to help you...
>
>> This makes it very problematic to support this platform.
>
> In general we could help with porting, in case issues arise, either pointing out problems or (as I did) sending patches when possible.
> Even if the current patch does not fixes all the issues exposed by running the test suite, at least allows the build as starting point in debugging the rest of the failures.
>
> --
> 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

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Brian had asked (2 years ago) if anybody has a VM available. I'm marking this as incomplete, as I think we need some help from the Hurd community to setup a testing VM.

Changed in gearmand:
status: New → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.