uclibc: add a missing function member to siginfo.h
PATCH 1/2 uclibc: add a missing function member to siginfo.h
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/
--- ...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
package/uclibc/0.9.32.1/uclibc-0009-siginfo_h-add-a-missing-function-member.patch new file +66 -0
@@ -0,0 +1,66 @@ +siginfo.h: add a missing function member on ia64, mips and sparc arches +Signed-off-by: Vicente Olivert Riera <[email protected]> + +From b4e6e61e2f7c6fb4bf59f66efaa74591a2112912 Mon Sep 17 00:00:00 2001 +From: Vicente Olivert Riera <[email protected]> +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 <[email protected]> +Signed-off-by: Bernhard Reutner-Fischer <[email protected]> +--- +(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
package/uclibc/0.9.33.2/uclibc-0055-siginfo_h-add-a-missing-function-member.patch new file +66 -0
66 lines not on this page · raw message
Signature · 1 line
1.7.1
PATCH 2/2 uclibc: Make __SIGEV_PAD_SIZE to take __WORDSIZE into account
Applying an upstream patch to make __SIGEV_PAD_SIZE to take __WORDSIZE into account for alpha, mips and ia64 arches.
Upstream patch URL:
http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux?id=b97b4b698b023f75b54f987859c856ab4861ea00
--- ...EV_PAD_SIZE-takes-__WORDSIZE-into-account.patch | 70 ++++++++++++++++++++ ...EV_PAD_SIZE-takes-__WORDSIZE-into-account.patch | 70 ++++++++++++++++++++ 2 files changed, 140 insertions(+), 0 deletions(-) create mode 100644 package/uclibc/0.9.32.1/uclibc-0010-siginfo_h-__SIGEV_PAD_SIZE-takes-__WORDSIZE-into-account.patch create mode 100644 package/uclibc/0.9.33.2/uclibc-0056-siginfo_h-__SIGEV_PAD_SIZE-takes-__WORDSIZE-into-account.patch
package/uclibc/0.9.32.1/uclibc-0010-siginfo_h-__SIGEV_PAD_SIZE-takes-__WORDSIZE-into-account.patch new file +70 -0
@@ -0,0 +1,70 @@ +siginfo.h: __SIGEV_PAD_SIZE takes __WORDSIZE into account +Signed-off-by: Vicente Olivert Riera <[email protected]> + +From b97b4b698b023f75b54f987859c856ab4861ea00 Mon Sep 17 00:00:00 2001 +From: Vicente Olivert Riera <[email protected]> +Date: Thu, 02 Jan 2014 15:02:12 +0000 +Subject: siginfo.h: __SIGEV_PAD_SIZE takes __WORDSIZE into account + +Make __SIGEV_PAD_SIZE to take __WORDSIZE into account for alpha, mips +and ia64 arches. + +Signed-off-by: Vicente Olivert Riera <[email protected]> +Signed-off-by: Bernhard Reutner-Fischer <[email protected]> +--- +(limited to 'libc/sysdeps/linux') + +diff --git a/libc/sysdeps/linux/alpha/bits/siginfo.h b/libc/sysdeps/linux/alpha/bits/siginfo.h +index 9993f66..0a37ad0 100644 +--- a/libc/sysdeps/linux/alpha/bits/siginfo.h ++++ b/libc/sysdeps/linux/alpha/bits/siginfo.h +@@ -257,7 +257,11 @@ enum + + /* Structure to transport application-defined values with signals. */ + # define __SIGEV_MAX_SIZE 64 +-# define __SIGEV_PAD_SIZE ((__SIGEV_MAX_SIZE / sizeof (int)) - 4) ++# if __WORDSIZE == 64 ++# define __SIGEV_PAD_SIZE ((__SIGEV_MAX_SIZE / sizeof (int)) - 4) ++# else ++# define __SIGEV_PAD_SIZE ((__SIGEV_MAX_SIZE / sizeof (int)) - 3) ++# endif + + typedef struct sigevent + { +diff --git a/libc/sysdeps/linux/ia64/bits/siginfo.h b/libc/sysdeps/linux/ia64/bits/siginfo.h +index 82cc73f..3ac988b 100644 +--- a/libc/sysdeps/linux/ia64/bits/siginfo.h ++++ b/libc/sysdeps/linux/ia64/bits/siginfo.h +@@ -297,7 +297,11 @@ enum + + /* Structure to transport application-defined values with signals. */ + # define __SIGEV_MAX_SIZE 64 +-# define __SIGEV_PAD_SIZE ((__SIGEV_MAX_SIZE / sizeof (int)) - 4) ++# if __WORDSIZE == 64 ++# define __SIGEV_PAD_SIZE ((__SIGEV_MAX_SIZE / sizeof (int)) - 4) ++# else ++# define __SIGEV_PAD_SIZE ((__SIGEV_MAX_SIZE / sizeof (int)) - 3) ++# endif + + typedef struct sigevent + { +diff --git a/libc/sysdeps/linux/mips/bits/siginfo.h b/libc/sysdeps/linux/mips/bits/siginfo.h +index 84b08ca..a6e4135 100644 +--- a/libc/sysdeps/linux/mips/bits/siginfo.h ++++ b/libc/sysdeps/linux/mips/bits/siginfo.h +@@ -264,8 +264,11 @@ enum + + /* Structure to transport application-defined values with signals. */ + # define __SIGEV_MAX_SIZE 64 +-# define __SIGEV_HEAD_SIZE (sizeof(long) + 2*sizeof(int)) +-# define __SIGEV_PAD_SIZE ((__SIGEV_MAX_SIZE - __SIGEV_HEAD_SIZE) / sizeof (int)) ++# if __WORDSIZE == 64 ++# define __SIGEV_PAD_SIZE ((__SIGEV_MAX_SIZE / sizeof (int)) - 4) ++# else ++# define __SIGEV_PAD_SIZE ((__SIGEV_MAX_SIZE / sizeof (int)) - 3) ++# endif + + /* Forward declaration of the `pthread_attr_t' type. */ + struct __pthread_attr_s; +-- +cgit v0.9.1
package/uclibc/0.9.33.2/uclibc-0056-siginfo_h-__SIGEV_PAD_SIZE-takes-__WORDSIZE-into-account.patch new file +70 -0
70 lines not on this page · raw message
Signature · 1 line
1.7.1
PATCH 2/2 uclibc: Make __SIGEV_PAD_SIZE to take __WORDSIZE into account
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
Applying an upstream patch to make
__SIGEV_PAD_SIZEto take__WORDSIZEinto account for alpha, mips and ia64 arches.Upstream patch URL:
http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux?id=b97b4b698b023f75b54f987859c856ab4861ea00Signed-off-by Vicente Olivert Riera <[email protected]>
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/2 uclibc: add a missing function member to siginfo.h
In reply to Vicente Olivert RieraDear Vicente Olivert Riera,
Quoted 10 lines · Vicente Olivert Riera
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=b4e6e61e2f7c6fb4bf59f66efaa74591a2112912Fixes:
http://autobuild.buildroot.net/results/fa0/fa03ecc087a4b30df8b0366bb238be3d167a56d9/Signed-off-by Vicente Olivert Riera <[email protected]>
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/2 uclibc: add a missing function member to siginfo.h
Quoted 23 lines · Thomas Petazzoni
Dear Vicente Olivert Riera,
Quoted 10 lines · Vicente Olivert Riera
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=b4e6e61e2f7c6fb4bf59f66efaa74591a2112912Fixes:
http://autobuild.buildroot.net/results/fa0/fa03ecc087a4b30df8b0366bb238be3d167a56d9/Signed-off-by Vicente Olivert Riera <[email protected]>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.
Quoted 8 lines
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,
Signature · 1 line
Vincent
PATCH 1/2 uclibc: add a missing function member to siginfo.h
Dear Vicente Olivert Riera,
Quoted 3 lines · Vicente Olivert Riera
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.
Quoted 7 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/2 uclibc: add a missing function member to siginfo.h
Quoted 52 lines · Thomas Petazzoni
Dear Vicente Olivert Riera,
Quoted 3 lines · Vicente Olivert Riera
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.
Quoted 7 lines
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.
Quoted 4 lines
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,
Signature · 1 line
Vincent
PATCH 1/2 uclibc: add a missing function member to siginfo.h
Dear Vicente Olivert Riera,
Quoted 4 lines · Vicente Olivert Riera
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 rt-tests: enable on MIPS uClibc again
In reply to Vicente Olivert RieraWe have fixes in the internal toolchain; an external toolchain is most likely a buildroot-built toolchain anyway, so it will also have the fix. But we still keep a comment to warn the user for potentially-broken external toolchains.
--- package/rt-tests/Config.in | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
package/rt-tests/Config.in +4 -5
@@ -1,8 +1,6 @@ config BR2_PACKAGE_RT_TESTS bool "rt-tests" # no _tid field in 'struct sigevent' - depends on !(BR2_TOOLCHAIN_USES_UCLIBC && (BR2_mips || BR2_mipsel || \ - BR2_mips64 || BR2_mips64el)) depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL help Set of utilities for testing the real-time behaviour of a
@@ -23,9 +21,10 @@ config BR2_PACKAGE_RT_TESTS http://rt.wiki.kernel.org -comment "rt-tests needs an (e)glibc toolchain" - depends on BR2_TOOLCHAIN_USES_UCLIBC && (BR2_mips || BR2_mipsel || \ - BR2_mips64 || BR2_mips64el) +comment "rt-tests may not work on MIPS with an external uClibc toolchain" + depends on BR2_PACKAGE_RT_TESTS + depends on BR2_TOOLCHAIN_EXTERNAL_UCLIBC + depends on BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el comment "rt-tests needs a toolchain w/ NPTL" depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL
Signature · 1 line
2.1.1
PATCH 1/1 rt-tests: enable on MIPS uClibc again
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle (Essensium/Mind) <[email protected]> writes:
We have fixes in the internal toolchain; an external toolchain is most likely a buildroot-built toolchain anyway, so it will also have the fix. But we still keep a comment to warn the user for potentially-broken external toolchains.
Cc Vicente Olivert Riera <[email protected]>
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/2 uclibc: add a missing function member to siginfo.h
In reply to Vicente Olivert RieraQuoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
Applying an upstream patch to add a missing function member on ia64, mips and sparc arches.
Quoted 7 lines
Upstream patch URL:
http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux?id=b4e6e61e2f7c6fb4bf59f66efaa74591a2112912Fixes:
http://autobuild.buildroot.net/results/fa0/fa03ecc087a4b30df8b0366bb238be3d167a56d9/Signed-off-by Vicente Olivert Riera <[email protected]>
Committed after the discussion at the dev days, thanks.
Signature · 1 line
Bye, Peter Korsgaard