Patchwork [1/2] uclibc: add a missing function member to siginfo.h

login
register
mail settings
Submitter Vicente Olivert Riera
Date Jan. 8, 2014, 5:32 p.m.
Message ID <1389202364-19387-1-git-send-email-Vincent.Riera@imgtec.com>
Download mbox | patch
Permalink /patch/308384/
State Accepted
Commit af9d0442cdc8d10e1be55beb02d422194c94a6f9
Headers show

Comments

Vicente Olivert Riera - Jan. 8, 2014, 5:32 p.m.
Applying an upstream patch to add a missing function member on ia64,
mips and sparc arches.

Upstream patch URL:
   http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux?id=b4e6e61e2f7c6fb4bf59f66efaa74591a2112912

Fixes:
   http://autobuild.buildroot.net/results/fa0/fa03ecc087a4b30df8b0366bb238be3d167a56d9/

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
 ...9-siginfo_h-add-a-missing-function-member.patch |   66 ++++++++++++++++++++
 ...5-siginfo_h-add-a-missing-function-member.patch |   66 ++++++++++++++++++++
 2 files changed, 132 insertions(+), 0 deletions(-)
 create mode 100644 package/uclibc/0.9.32.1/uclibc-0009-siginfo_h-add-a-missing-function-member.patch
 create mode 100644 package/uclibc/0.9.33.2/uclibc-0055-siginfo_h-add-a-missing-function-member.patch
Thomas Petazzoni - Jan. 9, 2014, 2:40 a.m.
Dear Vicente Olivert Riera,

On Wed, 8 Jan 2014 17:32:43 +0000, Vicente Olivert Riera wrote:
> Applying an upstream patch to add a missing function member on ia64,
> mips and sparc arches.
> 
> Upstream patch URL:
>    http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux?id=b4e6e61e2f7c6fb4bf59f66efaa74591a2112912
> 
> Fixes:
>    http://autobuild.buildroot.net/results/fa0/fa03ecc087a4b30df8b0366bb238be3d167a56d9/
> 
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>

Siggh. This is again the kind of things that will make package builds
work with internal uClibc toolchain, but fail badly with external
uClibc toolchains, which are likely to not contain the gazillions of
backported uClibc patches that we carry around.

I have the feeling that this is a growing problem, and I'm not sure how
to handle it. To me, the fact that the uClibc community is completely
inactive in terms of releases is really a major issue.

A solution would be to not support any uClibc based external toolchain,
but that means we would no longer support Blackfin external toolchains
for example, which is really not desirable.

Best regards,

Thomas
Vicente Olivert Riera - Jan. 9, 2014, 9:46 a.m.
On 01/09/2014 02:40 AM, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
>
> On Wed, 8 Jan 2014 17:32:43 +0000, Vicente Olivert Riera wrote:
>> Applying an upstream patch to add a missing function member on ia64,
>> mips and sparc arches.
>>
>> Upstream patch URL:
>>     http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux?id=b4e6e61e2f7c6fb4bf59f66efaa74591a2112912
>>
>> Fixes:
>>     http://autobuild.buildroot.net/results/fa0/fa03ecc087a4b30df8b0366bb238be3d167a56d9/
>>
>> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>
> Siggh. This is again the kind of things that will make package builds
> work with internal uClibc toolchain, but fail badly with external
> uClibc toolchains, which are likely to not contain the gazillions of
> backported uClibc patches that we carry around.
>
> I have the feeling that this is a growing problem, and I'm not sure how
> to handle it. To me, the fact that the uClibc community is completely
> inactive in terms of releases is really a major issue.
>
> A solution would be to not support any uClibc based external toolchain,
> but that means we would no longer support Blackfin external toolchains
> for example, which is really not desirable.
>
> Best regards,
>
> Thomas
>

Yes, I understand what you mean, but what do you want to do? I mean, if 
uClibc don't release new version, aren't you going to upgrade external 
toolchains anymore?

I think we should fix this for the Buildroot toolchain, because is "our" 
toolchain and is "our" problem. If external toolchains don't apply those 
patches, then that will be their problem. They can upgrade the toolchain 
packaging uClibc to a git version number, so no releases is needed. Of 
course I understand that having a release is better because that means 
that the state is consistent, it shouldn't fail, has been tested, etc., 
but if that's not happening, again, is not our problem.

Best regards,
Thomas Petazzoni - Jan. 10, 2014, 7:36 a.m.
Dear Vicente Olivert Riera,

On Thu, 9 Jan 2014 09:46:13 +0000, Vicente Olivert Riera wrote:

> Yes, I understand what you mean, but what do you want to do? I mean, if 
> uClibc don't release new version, aren't you going to upgrade external 
> toolchains anymore?

Depends on which external toolchains we're talking about. In the
autobuilders, there are various external toolchains that are in use.
Amongst the uClibc based ones, we have:

 * Toolchains built using Buildroot itself. These are not very
   problematic, as I can rebuild them when a new version of Buildroot
   containing useful backported uClibc patches is released. Though it'd
   be great if I wasn't forced to rebuild these toolchains too often.

 * Toolchains built using Crosstool-NG. Those will *not* contain the
   backported uClibc patches that we have in Buildroot. There is a lot
   less uClibc patch backporting activity going on in Crosstool-NG, if
   any.

 * Toolchains coming from vendors, such as the Analog Devices
   toolchain. There's nothing we can do about them.

Therefore, having Buildroot packages relying on so many backported
uClibc patches is getting more and more problematic.

> I think we should fix this for the Buildroot toolchain, because is "our" 
> toolchain and is "our" problem. If external toolchains don't apply those 
> patches, then that will be their problem. They can upgrade the toolchain 
> packaging uClibc to a git version number, so no releases is needed. Of 
> course I understand that having a release is better because that means 
> that the state is consistent, it shouldn't fail, has been tested, etc., 
> but if that's not happening, again, is not our problem.

I think this is completely the wrong way of seeing things. Buildroot's
policy is that we should deviate as little as possible from upstream.
We don't have the man-power to maintain our own set of crazy patches on
top of this or that component. Whenever someone wanted to post patches
adding features to this or that component, we've always rejected them,
and encouraged the contributor to get them merged in the upstream
component instead.

I think it should be the same with uClibc. If some package doesn't work
with an uClibc release, then we should simply exclude this package
entirely from being built with any uClibc toolchain. And if people are
not happy with that, then they should either engage with the
upstream uClibc to ensure that they do releases at reasonable
intervals, or they should realize that uClibc is a near-dead project,
and therefore that switching to another C library probably makes sense.

Best regards,

Thomas
Vicente Olivert Riera - Jan. 10, 2014, 10:10 a.m.
On 01/10/2014 07:36 AM, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
>
> On Thu, 9 Jan 2014 09:46:13 +0000, Vicente Olivert Riera wrote:
>
>> Yes, I understand what you mean, but what do you want to do? I mean, if
>> uClibc don't release new version, aren't you going to upgrade external
>> toolchains anymore?
>
> Depends on which external toolchains we're talking about. In the
> autobuilders, there are various external toolchains that are in use.
> Amongst the uClibc based ones, we have:
>
>   * Toolchains built using Buildroot itself. These are not very
>     problematic, as I can rebuild them when a new version of Buildroot
>     containing useful backported uClibc patches is released. Though it'd
>     be great if I wasn't forced to rebuild these toolchains too often.
>
>   * Toolchains built using Crosstool-NG. Those will *not* contain the
>     backported uClibc patches that we have in Buildroot. There is a lot
>     less uClibc patch backporting activity going on in Crosstool-NG, if
>     any.
>
>   * Toolchains coming from vendors, such as the Analog Devices
>     toolchain. There's nothing we can do about them.
>
> Therefore, having Buildroot packages relying on so many backported
> uClibc patches is getting more and more problematic.
>
>> I think we should fix this for the Buildroot toolchain, because is "our"
>> toolchain and is "our" problem. If external toolchains don't apply those
>> patches, then that will be their problem. They can upgrade the toolchain
>> packaging uClibc to a git version number, so no releases is needed. Of
>> course I understand that having a release is better because that means
>> that the state is consistent, it shouldn't fail, has been tested, etc.,
>> but if that's not happening, again, is not our problem.
>
> I think this is completely the wrong way of seeing things. Buildroot's
> policy is that we should deviate as little as possible from upstream.
> We don't have the man-power to maintain our own set of crazy patches on
> top of this or that component. Whenever someone wanted to post patches
> adding features to this or that component, we've always rejected them,
> and encouraged the contributor to get them merged in the upstream
> component instead.
>
> I think it should be the same with uClibc. If some package doesn't work
> with an uClibc release, then we should simply exclude this package
> entirely from being built with any uClibc toolchain. And if people are
> not happy with that, then they should either engage with the
> upstream uClibc to ensure that they do releases at reasonable
> intervals, or they should realize that uClibc is a near-dead project,
> and therefore that switching to another C library probably makes sense.
>
> Best regards,
>
> Thomas
>

Hello Thomas.

So I understand that your suggestion is to not apply uClibc patches in 
Buildroot anymore and just disable the packages (the ones that are 
failing) for the affected uClibc versions, and keep them enabled when 
the uClibc daily snapshot is selected. Am I right?

Best regards,
Thomas Petazzoni - Jan. 28, 2014, 9:25 p.m.
Dear Vicente Olivert Riera,

On Fri, 10 Jan 2014 10:10:50 +0000, Vicente Olivert Riera wrote:

> So I understand that your suggestion is to not apply uClibc patches in 
> Buildroot anymore and just disable the packages (the ones that are 
> failing) for the affected uClibc versions, and keep them enabled when 
> the uClibc daily snapshot is selected. Am I right?

This would be my preferred solution yes. This way, people would
probably realize how broken the uClibc release process is, and would
maybe be encouraged to work with upstream.

I've added this topic as a discussion item for the upcoming Buildroot
Developers meeting.

Thomas
Peter Korsgaard - Oct. 12, 2014, 7:46 a.m.
>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:

 > Applying an upstream patch to add a missing function member on ia64,
 > mips and sparc arches.

 > Upstream patch URL:
 >    http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux?id=b4e6e61e2f7c6fb4bf59f66efaa74591a2112912

 > Fixes:
 >    http://autobuild.buildroot.net/results/fa0/fa03ecc087a4b30df8b0366bb238be3d167a56d9/

 > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>

Committed after the discussion at the dev days, thanks.

Patch

diff --git a/package/uclibc/0.9.32.1/uclibc-0009-siginfo_h-add-a-missing-function-member.patch b/package/uclibc/0.9.32.1/uclibc-0009-siginfo_h-add-a-missing-function-member.patch
new file mode 100644
index 0000000..1a837bb
--- /dev/null
+++ b/package/uclibc/0.9.32.1/uclibc-0009-siginfo_h-add-a-missing-function-member.patch
@@ -0,0 +1,66 @@ 
+siginfo.h: add a missing function member on ia64, mips and sparc arches
+Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
+
+From b4e6e61e2f7c6fb4bf59f66efaa74591a2112912 Mon Sep 17 00:00:00 2001
+From: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
+Date: Thu, 02 Jan 2014 15:02:11 +0000
+Subject: siginfo.h: add a missing function member on ia64, mips and sparc arches
+
+Add "__pid_t _tid" member which is used for some packages, like rt-test
+for instance, which fails with an error like this one:
+
+src/cyclictest/cyclictest.c:638:9: error: 'union <anonymous>' has no
+member named '_tid'
+
+Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
+Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
+---
+(limited to 'libc/sysdeps/linux')
+
+diff --git a/libc/sysdeps/linux/ia64/bits/siginfo.h b/libc/sysdeps/linux/ia64/bits/siginfo.h
+index f571f46..82cc73f 100644
+--- a/libc/sysdeps/linux/ia64/bits/siginfo.h
++++ b/libc/sysdeps/linux/ia64/bits/siginfo.h
+@@ -309,6 +309,10 @@ typedef struct sigevent
+       {
+ 	int _pad[__SIGEV_PAD_SIZE];
+ 
++	/* When SIGEV_SIGNAL and SIGEV_THREAD_ID set, LWP ID of the
++	   thread to receive the signal.  */
++	__pid_t _tid;
++
+ 	struct
+ 	  {
+ 	    void (*_function) (sigval_t);	/* Function to start.  */
+diff --git a/libc/sysdeps/linux/mips/bits/siginfo.h b/libc/sysdeps/linux/mips/bits/siginfo.h
+index 79fb15a..84b08ca 100644
+--- a/libc/sysdeps/linux/mips/bits/siginfo.h
++++ b/libc/sysdeps/linux/mips/bits/siginfo.h
+@@ -281,6 +281,10 @@ typedef struct sigevent
+       {
+ 	int _pad[__SIGEV_PAD_SIZE];
+ 
++	/* When SIGEV_SIGNAL and SIGEV_THREAD_ID set, LWP ID of the
++	   thread to receive the signal.  */
++	__pid_t _tid;
++
+ 	struct
+ 	  {
+ 	    void (*_function) (sigval_t);	/* Function to start.  */
+diff --git a/libc/sysdeps/linux/sparc/bits/siginfo.h b/libc/sysdeps/linux/sparc/bits/siginfo.h
+index 6f2d035..3ffeb6d 100644
+--- a/libc/sysdeps/linux/sparc/bits/siginfo.h
++++ b/libc/sysdeps/linux/sparc/bits/siginfo.h
+@@ -288,6 +288,10 @@ typedef struct sigevent
+       {
+ 	int _pad[__SIGEV_PAD_SIZE];
+ 
++	/* When SIGEV_SIGNAL and SIGEV_THREAD_ID set, LWP ID of the
++	   thread to receive the signal.  */
++	__pid_t _tid;
++
+ 	struct
+ 	  {
+ 	    void (*_function) (sigval_t);	/* Function to start.  */
+--
+cgit v0.9.1
diff --git a/package/uclibc/0.9.33.2/uclibc-0055-siginfo_h-add-a-missing-function-member.patch b/package/uclibc/0.9.33.2/uclibc-0055-siginfo_h-add-a-missing-function-member.patch
new file mode 100644
index 0000000..1a837bb
--- /dev/null
+++ b/package/uclibc/0.9.33.2/uclibc-0055-siginfo_h-add-a-missing-function-member.patch
@@ -0,0 +1,66 @@ 
+siginfo.h: add a missing function member on ia64, mips and sparc arches
+Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
+
+From b4e6e61e2f7c6fb4bf59f66efaa74591a2112912 Mon Sep 17 00:00:00 2001
+From: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
+Date: Thu, 02 Jan 2014 15:02:11 +0000
+Subject: siginfo.h: add a missing function member on ia64, mips and sparc arches
+
+Add "__pid_t _tid" member which is used for some packages, like rt-test
+for instance, which fails with an error like this one:
+
+src/cyclictest/cyclictest.c:638:9: error: 'union <anonymous>' has no
+member named '_tid'
+
+Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
+Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
+---
+(limited to 'libc/sysdeps/linux')
+
+diff --git a/libc/sysdeps/linux/ia64/bits/siginfo.h b/libc/sysdeps/linux/ia64/bits/siginfo.h
+index f571f46..82cc73f 100644
+--- a/libc/sysdeps/linux/ia64/bits/siginfo.h
++++ b/libc/sysdeps/linux/ia64/bits/siginfo.h
+@@ -309,6 +309,10 @@ typedef struct sigevent
+       {
+ 	int _pad[__SIGEV_PAD_SIZE];
+ 
++	/* When SIGEV_SIGNAL and SIGEV_THREAD_ID set, LWP ID of the
++	   thread to receive the signal.  */
++	__pid_t _tid;
++
+ 	struct
+ 	  {
+ 	    void (*_function) (sigval_t);	/* Function to start.  */
+diff --git a/libc/sysdeps/linux/mips/bits/siginfo.h b/libc/sysdeps/linux/mips/bits/siginfo.h
+index 79fb15a..84b08ca 100644
+--- a/libc/sysdeps/linux/mips/bits/siginfo.h
++++ b/libc/sysdeps/linux/mips/bits/siginfo.h
+@@ -281,6 +281,10 @@ typedef struct sigevent
+       {
+ 	int _pad[__SIGEV_PAD_SIZE];
+ 
++	/* When SIGEV_SIGNAL and SIGEV_THREAD_ID set, LWP ID of the
++	   thread to receive the signal.  */
++	__pid_t _tid;
++
+ 	struct
+ 	  {
+ 	    void (*_function) (sigval_t);	/* Function to start.  */
+diff --git a/libc/sysdeps/linux/sparc/bits/siginfo.h b/libc/sysdeps/linux/sparc/bits/siginfo.h
+index 6f2d035..3ffeb6d 100644
+--- a/libc/sysdeps/linux/sparc/bits/siginfo.h
++++ b/libc/sysdeps/linux/sparc/bits/siginfo.h
+@@ -288,6 +288,10 @@ typedef struct sigevent
+       {
+ 	int _pad[__SIGEV_PAD_SIZE];
+ 
++	/* When SIGEV_SIGNAL and SIGEV_THREAD_ID set, LWP ID of the
++	   thread to receive the signal.  */
++	__pid_t _tid;
++
+ 	struct
+ 	  {
+ 	    void (*_function) (sigval_t);	/* Function to start.  */
+--
+cgit v0.9.1