[Buildroot] [PATCH] boost: fix build on ARC

[Buildroot] [PATCH] boost: fix build on ARC

[Thomas Petazzoni]

This commit adds a patch to Boost to make it use the eventfd()
function provided by the C library when uClibc is used, rather than
falling back to using directly the __NR_eventfd system call. This
fixes the build on ARC, which doesn't define __NR_eventfd.

The original problem is that uClibc fakes to be glibc 2.2, which
didn't had eventfd(), so Boost makes the system call
manually. uClibc-ng, in its next release, will pretend to be glibc
2.10 (see
http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=4ff3a6c8eb91db71d6dc3d2932b66e848bd20ac3),
which will also fix the problem, but requires bumping the uClibc
version, rebuilding the external toolchains, and so on.

Ideally, Boost should be doing a compile test to detect if eventfd()
is available or not, but the Boost build system is so brain-damage
that doing so would require way too much effort.

Fixes:

  http://autobuild.buildroot.org/results/22b/22b710346d2cd78b7b51cdccd18d670bb6ac5d24/
  and many similar build failures

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/boost/0004-fix-uclibc-eventfd.patch | 38 +++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
 create mode 100644 package/boost/0004-fix-uclibc-eventfd.patch

diff --git a/package/boost/0004-fix-uclibc-eventfd.patch b/package/boost/0004-fix-uclibc-eventfd.patch
new file mode 100644
index 0000000..1b7eb87
--- /dev/null
+++ b/package/boost/0004-fix-uclibc-eventfd.patch
@@ -0,0 +1,38 @@
+Use eventfd() function with uClibc
+
+The Boost eventfd code either directly makes the eventfd system call
+using __NR_eventfd (when __GLIBC_MINOR is less than 8), or otherwise
+uses the eventfd() function provided by the C library.
+
+However, since uClibc pretends to be glibc 2.2, the Boost eventfd code
+directly uses the system call. While it works fine on most
+architectures, it doesn't on ARC since __NR_eventfd is not defined on
+this architecture. However, eventfd() is properly implemented.
+
+So, this patch adjusts the logic used by Boost to consider uClibc as a
+C library providing the eventfd() function.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+Index: b/boost/asio/detail/impl/eventfd_select_interrupter.ipp
+===================================================================
+--- a/boost/asio/detail/impl/eventfd_select_interrupter.ipp
++++ b/boost/asio/detail/impl/eventfd_select_interrupter.ipp
+@@ -23,7 +23,7 @@
+ #include <sys/stat.h>
+ #include <sys/types.h>
+ #include <fcntl.h>
+-#if __GLIBC__ == 2 && __GLIBC_MINOR__ < 8
++#if __GLIBC__ == 2 && __GLIBC_MINOR__ < 8 && !defined(__UCLIBC__)
+ # include <asm/unistd.h>
+ #else // __GLIBC__ == 2 && __GLIBC_MINOR__ < 8
+ # include <sys/eventfd.h>
+@@ -46,7 +46,7 @@
+ 
+ void eventfd_select_interrupter::open_descriptors()
+ {
+-#if __GLIBC__ == 2 && __GLIBC_MINOR__ < 8
++#if __GLIBC__ == 2 && __GLIBC_MINOR__ < 8 && !defined(__UCLIBC__)
+   write_descriptor_ = read_descriptor_ = syscall(__NR_eventfd, 0);
+   if (read_descriptor_ != -1)
+   {
-- 
2.5.0

[Buildroot] [PATCH] boost: fix build on ARC

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > This commit adds a patch to Boost to make it use the eventfd()
 > function provided by the C library when uClibc is used, rather than
 > falling back to using directly the __NR_eventfd system call. This
 > fixes the build on ARC, which doesn't define __NR_eventfd.

What does it then do? Only __NR_eventfd2?

 > The original problem is that uClibc fakes to be glibc 2.2, which
 > didn't had eventfd(), so Boost makes the system call
 > manually. uClibc-ng, in its next release, will pretend to be glibc
 > 2.10 (see
 > http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=4ff3a6c8eb91db71d6dc3d2932b66e848bd20ac3),
 > which will also fix the problem, but requires bumping the uClibc
 > version, rebuilding the external toolchains, and so on.

 > Ideally, Boost should be doing a compile test to detect if eventfd()
 > is available or not, but the Boost build system is so brain-damage

s/damage/damaged/

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] boost: fix build on ARC

[Thomas Petazzoni]

Peter,

On Wed, 19 Aug 2015 22:57:56 +0200, Peter Korsgaard wrote:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> 
>  > This commit adds a patch to Boost to make it use the eventfd()
>  > function provided by the C library when uClibc is used, rather than
>  > falling back to using directly the __NR_eventfd system call. This
>  > fixes the build on ARC, which doesn't define __NR_eventfd.
> 
> What does it then do? Only __NR_eventfd2?

I am not sure. Alexey?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] boost: fix build on ARC

[Alexey Brodkin]

Hi Thomas,

> -----Original Message-----
> From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
> Sent: 19 ??????? 2015 ?. 21:27
> To: buildroot at uclibc.org
> Cc: Alexey Brodkin; Thomas Petazzoni
> Subject: [PATCH] boost: fix build on ARC
> 
> This commit adds a patch to Boost to make it use the eventfd() function provided by the C library when uClibc is used, rather than
> falling back to using directly the __NR_eventfd system call. This fixes the build on ARC, which doesn't define __NR_eventfd.
> 
> The original problem is that uClibc fakes to be glibc 2.2, which didn't had eventfd(), so Boost makes the system call manually. uClibc-ng,
> in its next release, will pretend to be glibc
> 2.10 (see
> http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=4ff3a6c8eb91db71d6dc3d2932b66e848bd20ac3),
> which will also fix the problem, but requires bumping the uClibc version, rebuilding the external toolchains, and so on.
> 
> Ideally, Boost should be doing a compile test to detect if eventfd() is available or not, but the Boost build system is so brain-damage
> that doing so would require way too much effort.
> 
> Fixes:
> 
>   http://autobuild.buildroot.org/results/22b/22b710346d2cd78b7b51cdccd18d670bb6ac5d24/
>   and many similar build failures
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  package/boost/0004-fix-uclibc-eventfd.patch | 38 +++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
>  create mode 100644 package/boost/0004-fix-uclibc-eventfd.patch
> 
> diff --git a/package/boost/0004-fix-uclibc-eventfd.patch b/package/boost/0004-fix-uclibc-eventfd.patch
> new file mode 100644
> index 0000000..1b7eb87
> --- /dev/null
> +++ b/package/boost/0004-fix-uclibc-eventfd.patch
> @@ -0,0 +1,38 @@
> +Use eventfd() function with uClibc
> +
> +The Boost eventfd code either directly makes the eventfd system call
> +using __NR_eventfd (when __GLIBC_MINOR is less than 8), or otherwise
> +uses the eventfd() function provided by the C library.
> +
> +However, since uClibc pretends to be glibc 2.2, the Boost eventfd code
> +directly uses the system call. While it works fine on most
> +architectures, it doesn't on ARC since __NR_eventfd is not defined on
> +this architecture. However, eventfd() is properly implemented.
> +
> +So, this patch adjusts the logic used by Boost to consider uClibc as a
> +C library providing the eventfd() function.
> +
> +Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> +
> +Index: b/boost/asio/detail/impl/eventfd_select_interrupter.ipp
> +===================================================================
> +--- a/boost/asio/detail/impl/eventfd_select_interrupter.ipp
> ++++ b/boost/asio/detail/impl/eventfd_select_interrupter.ipp
> +@@ -23,7 +23,7 @@
> + #include <sys/stat.h>
> + #include <sys/types.h>
> + #include <fcntl.h>
> +-#if __GLIBC__ == 2 && __GLIBC_MINOR__ < 8
> ++#if __GLIBC__ == 2 && __GLIBC_MINOR__ < 8 && !defined(__UCLIBC__)
> + # include <asm/unistd.h>
> + #else // __GLIBC__ == 2 && __GLIBC_MINOR__ < 8  # include
> +<sys/eventfd.h> @@ -46,7 +46,7 @@
> +
> + void eventfd_select_interrupter::open_descriptors()
> + {
> +-#if __GLIBC__ == 2 && __GLIBC_MINOR__ < 8
> ++#if __GLIBC__ == 2 && __GLIBC_MINOR__ < 8 && !defined(__UCLIBC__)
> +   write_descriptor_ = read_descriptor_ = syscall(__NR_eventfd, 0);
> +   if (read_descriptor_ != -1)
> +   {
> --
> 2.5.0

Even though it's good to have this patch for fixing Boost building I'm not sure
what this hack causes in runtime. Remember I mentioned these checks for
GLIBC version are spread all around their sources.

Anyways I see it is already applied so let's live with it for now.
And I assume once:
 [1] ARC switches from GitHub based uClibc  to uClibc-ng in Buildroot
 [2] uClibc-ng bumps to 1.0.6
we'll get rid of that patch, correct?

-Alexey

[Buildroot] [PATCH] boost: fix build on ARC

[Alexey Brodkin]

Hi Peter, Thomas,

> -----Original Message-----
> From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
> Sent: 20 ??????? 2015 ?. 0:04
> To: Peter Korsgaard
> Cc: buildroot at uclibc.org; Alexey Brodkin
> Subject: Re: [PATCH] boost: fix build on ARC
> 
> Peter,
> 
> On Wed, 19 Aug 2015 22:57:56 +0200, Peter Korsgaard wrote:
> > >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> >
> >  > This commit adds a patch to Boost to make it use the eventfd()
> >  > function provided by the C library when uClibc is used, rather than
> >  > falling back to using directly the __NR_eventfd system call. This
> >  > fixes the build on ARC, which doesn't define __NR_eventfd.
> >
> > What does it then do? Only __NR_eventfd2?

In case of ARC as being one of very few architectures that closely follow kernel's UAPI
we don't support lots of obsolete things and __NR_eventfd is one of them.
And indeed __NR_eventfd2 is supported.

For a bit more details pls refer to this explanation:
http://lists.boost.org/Archives/boost/2015/07/224257.php

-Alexey

[Buildroot] [PATCH] boost: fix build on ARC

[Thomas Petazzoni]

Alexey,

On Thu, 20 Aug 2015 08:26:52 +0000, Alexey Brodkin wrote:

> Even though it's good to have this patch for fixing Boost building I'm not sure
> what this hack causes in runtime. Remember I mentioned these checks for
> GLIBC version are spread all around their sources.

It fixes that particular problem. There may indeed be other problems,
which we can only resolve by having ARC users running Boost based
applications.

> Anyways I see it is already applied so let's live with it for now.
> And I assume once:
>  [1] ARC switches from GitHub based uClibc  to uClibc-ng in Buildroot
>  [2] uClibc-ng bumps to 1.0.6
> we'll get rid of that patch, correct?

Yes, of course, once the _GLIBC_MINOR bump is in a released version of
uClibc-ng, and we have rebuilt the external toolchains, we will drop
this patch from Boost. Do not hesitate to send such a patch series when
time comes.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com