| Message ID | 1389202364-19387-1-git-send-email-Vincent.Riera@imgtec.com |
|---|---|
| State | Accepted |
| Commit | af9d0442cdc8d10e1be55beb02d422194c94a6f9 |
| Headers | show |
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
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,
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
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,
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
>>>>> "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.
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
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