[Buildroot] [git commit branch/next] uClibc: fix sparc build breakage

[Buildroot] [git commit branch/next] uClibc: fix sparc build breakage

[Peter Korsgaard]

commit: http://git.buildroot.net/buildroot/commit/?id=b847ed050d85e7b0befc5521f4acff7cc1f31693
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/next

Fix build breakage for sparc as reported in bug #4021
Patches from Konrad Eisele <konrad@gaisler.com>
Submitted in the uclibc mailing list.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 .../uClibc/uClibc-0.9.31.1-sparc-errno-fix.patch   |   11 +++++++++++
 .../uClibc/uClibc-0.9.32-sparc-errno-fix.patch     |   11 +++++++++++
 2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/toolchain/uClibc/uClibc-0.9.31.1-sparc-errno-fix.patch b/toolchain/uClibc/uClibc-0.9.31.1-sparc-errno-fix.patch
new file mode 100644
index 0000000..44d06cb
--- /dev/null
+++ b/toolchain/uClibc/uClibc-0.9.31.1-sparc-errno-fix.patch
@@ -0,0 +1,11 @@
+--- uClibc-0.9.32.ori/libc/sysdeps/linux/sparc/pipe.S	2011-06-08 21:35:20.000000000 +0200
++++ uClibc-0.9.32/libc/sysdeps/linux/sparc/pipe.S	2011-11-11 15:57:25.000000000 +0100
+@@ -52,7 +52,7 @@
+ 	 restore %g0,%g0,%o0
+ 
+ .Lerror:
+-	call	HIDDEN_JUMPTARGET(__errno_location)
++	call	__errno_location
+ 	 or	%g0,EINVAL,%i0
+ 	st	%i0,[%o0]
+ 	ret
diff --git a/toolchain/uClibc/uClibc-0.9.32-sparc-errno-fix.patch b/toolchain/uClibc/uClibc-0.9.32-sparc-errno-fix.patch
new file mode 100644
index 0000000..44d06cb
--- /dev/null
+++ b/toolchain/uClibc/uClibc-0.9.32-sparc-errno-fix.patch
@@ -0,0 +1,11 @@
+--- uClibc-0.9.32.ori/libc/sysdeps/linux/sparc/pipe.S	2011-06-08 21:35:20.000000000 +0200
++++ uClibc-0.9.32/libc/sysdeps/linux/sparc/pipe.S	2011-11-11 15:57:25.000000000 +0100
+@@ -52,7 +52,7 @@
+ 	 restore %g0,%g0,%o0
+ 
+ .Lerror:
+-	call	HIDDEN_JUMPTARGET(__errno_location)
++	call	__errno_location
+ 	 or	%g0,EINVAL,%i0
+ 	st	%i0,[%o0]
+ 	ret

[Buildroot] [git commit branch/next] uClibc: fix sparc build breakage

[Michael S. Zick]

On Fri November 11 2011, Peter Korsgaard wrote:
> Fix build breakage for sparc as reported in bug #4021
> Patches from Konrad Eisele <konrad@gaisler.com>
> Submitted in the uclibc mailing list.
> 

Opens a question or two that did not get covered in the
discussion about using a '-next' branch.

A policy statement for when bug reports get cleared?
When -next receives the patch?
Just prior to when the current -next becomes the next -rc?
(I think the second is the current policy.)

In the case of a patch that is submitted upstream and the
additional month of committing patches (beginning in -next);
The chance that 'upstream' will release a revised source
before our -next becomes -rc is greater.

I think the current practice is to revert any patch(s) at the
same time the source version gets bumped.
And, clear any corresponding bug report (if the submitter is
aware of them).

Would it help the bug report review process done just prior
to the -rc version if there was a selectable flag in the
tracker system that let the reviewer select all the reports
subject to "patch sent upstream"?

Mike

[Buildroot] [git commit branch/next] uClibc: fix sparc build breakage

[Gustavo Zacarias]

On 11.11.2011 18:33, Michael S. Zick wrote:

> Opens a question or two that did not get covered in the
> discussion about using a '-next' branch.
>
> A policy statement for when bug reports get cleared?
> When -next receives the patch?
> Just prior to when the current -next becomes the next -rc?
> (I think the second is the current policy.)

Yes the later is the common practice, hence the reason neither Peter 
nor I closed the bug.

> In the case of a patch that is submitted upstream and the
> additional month of committing patches (beginning in -next);
> The chance that 'upstream' will release a revised source
> before our -next becomes -rc is greater.

That depends, uClibc is a special case where we keep a couple of 
versions around.
Let's suppose version 0.9.33 gets out, then it'll most certainly be 
fixed, but if there's no 0.9.32.1 the patch will still apply to that 
tree.
Not every project around has a release schedule like buildroot so we 
probably need to be flexible about it.
Regards.