[Buildroot] [PATCH] libmpeg2: fix sparc32 build

[Buildroot] [PATCH] libmpeg2: fix sparc32 build

[Waldemar Brodkorb]

The output detection recognized wrong target output, because
sparcv9 optimization flags used for sparcv8 build.

Fixes:
  http://autobuild.buildroot.net/results/1b3158b03f7eaf5afb5a4dab9526091888f6c9b8

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
---
 package/libmpeg2/0004-fix-sparc.patch | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100644 package/libmpeg2/0004-fix-sparc.patch

diff --git a/package/libmpeg2/0004-fix-sparc.patch b/package/libmpeg2/0004-fix-sparc.patch
new file mode 100644
index 0000000..d876b66
--- /dev/null
+++ b/package/libmpeg2/0004-fix-sparc.patch
@@ -0,0 +1,16 @@
+Do not use sparcv9 optimization flags for sparcv8 builds
+
+Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
+
+diff -Nur libmpeg2-0.5.1.orig/configure.ac libmpeg2-0.5.1/configure.ac
+--- libmpeg2-0.5.1.orig/configure.ac	2008-07-18 16:30:17.000000000 +0200
++++ libmpeg2-0.5.1/configure.ac	2017-04-26 21:09:15.780838339 +0200
+@@ -95,7 +95,7 @@
+ 		break
+ 	    fi
+ 	done;;
+-    sparc-* | sparc64-*)
++    sparc64-*)
+ 	AC_DEFINE([ARCH_SPARC],,[sparc architecture])
+ 	TRY_CFLAGS="$OPT_CFLAGS -mcpu=ultrasparc -mvis"
+ 	AC_TRY_CFLAGS([$TRY_CFLAGS $CFLAGS],[OPT_CFLAGS="$TRY_CFLAGS"]);;
-- 
2.1.4

[Buildroot] [PATCH] libmpeg2: fix sparc32 build

[Peter Korsgaard]

>>>>> "Waldemar" == Waldemar Brodkorb <wbx@openadk.org> writes:

 > The output detection recognized wrong target output, because
 > sparcv9 optimization flags used for sparcv8 build.

 > Fixes:
 >   http://autobuild.buildroot.net/results/1b3158b03f7eaf5afb5a4dab9526091888f6c9b8

 > Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>

Committed, thanks. Don't forget to submit it upstream as well.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] libmpeg2: fix sparc32 build

[Waldemar Brodkorb]

Hi Peter,
Peter Korsgaard wrote,

> >>>>> "Waldemar" == Waldemar Brodkorb <wbx@openadk.org> writes:
> 
>  > The output detection recognized wrong target output, because
>  > sparcv9 optimization flags used for sparcv8 build.
> 
>  > Fixes:
>  >   http://autobuild.buildroot.net/results/1b3158b03f7eaf5afb5a4dab9526091888f6c9b8
> 
>  > Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
> 
> Committed, thanks. Don't forget to submit it upstream as well.

Upstream looks very inactive to me, I don't think I will submit it there.

best
 Waldemar

[Buildroot] [PATCH] libmpeg2: fix sparc32 build

[Thomas Petazzoni]

Hello,

On Thu, 27 Apr 2017 07:36:09 +0200, Waldemar Brodkorb wrote:

> +-    sparc-* | sparc64-*)
> ++    sparc64-*)
> + 	AC_DEFINE([ARCH_SPARC],,[sparc architecture])
> + 	TRY_CFLAGS="$OPT_CFLAGS -mcpu=ultrasparc -mvis"
> + 	AC_TRY_CFLAGS([$TRY_CFLAGS $CFLAGS],[OPT_CFLAGS="$TRY_CFLAGS"]);;

I am not sure this is the completely correct solution, and Arnout
proposed another solution, see:

  https://patchwork.ozlabs.org/patch/749138/
  https://patchwork.ozlabs.org/patch/749137/

The second patch has the explanation why Waldemar patch is not really
correct.

Best regards,

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

[Buildroot] [PATCH] libmpeg2: fix sparc32 build

[Peter Korsgaard]

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

 > Hello,
 > On Thu, 27 Apr 2017 07:36:09 +0200, Waldemar Brodkorb wrote:

 >> +-    sparc-* | sparc64-*)
 >> ++    sparc64-*)
 >> + 	AC_DEFINE([ARCH_SPARC],,[sparc architecture])
 >> + 	TRY_CFLAGS="$OPT_CFLAGS -mcpu=ultrasparc -mvis"
 >> + 	AC_TRY_CFLAGS([$TRY_CFLAGS $CFLAGS],[OPT_CFLAGS="$TRY_CFLAGS"]);;

 > I am not sure this is the completely correct solution, and Arnout
 > proposed another solution, see:

 >   https://patchwork.ozlabs.org/patch/749138/
 >   https://patchwork.ozlabs.org/patch/749137/

 > The second patch has the explanation why Waldemar patch is not really
 > correct.

Ok. Can I take this as an acked-by for the check-bin-arch / pkg-generic
changes then? ;)

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] libmpeg2: fix sparc32 build

[Thomas Petazzoni]

Hello,

On Thu, 27 Apr 2017 11:15:34 +0200, Peter Korsgaard wrote:

>  > I am not sure this is the completely correct solution, and Arnout
>  > proposed another solution, see:  
> 
>  >   https://patchwork.ozlabs.org/patch/749138/
>  >   https://patchwork.ozlabs.org/patch/749137/  
> 
>  > The second patch has the explanation why Waldemar patch is not really
>  > correct.  
> 
> Ok. Can I take this as an acked-by for the check-bin-arch / pkg-generic
> changes then? ;)

I haven't reviewed the implementation details, but on the general
principles, yes, I'm OK. It's a bit annoying to extend the package
infrastructure for such a specific case, but I don't really see a
better solution here, except hacking libmpeg2 to remove the runtime
detection logic.

On the other hand, do we care enough about libmpeg2 on SPARC to extend
the package infrastructure just for this purpose? In the end, even if
Waldemar's solution is not "correct", it avoids the need to extend the
package infrastructure just for a purpose of a single package that will
most likely never ever be used on SPARC.

Arnout, what do you think?

Best regards,

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

[Buildroot] [PATCH] libmpeg2: fix sparc32 build

[Arnout Vandecappelle]

On 27-04-17 11:22, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 27 Apr 2017 11:15:34 +0200, Peter Korsgaard wrote:
> 
>>  > I am not sure this is the completely correct solution, and Arnout
>>  > proposed another solution, see:  
>>
>>  >   https://patchwork.ozlabs.org/patch/749138/
>>  >   https://patchwork.ozlabs.org/patch/749137/  
>>
>>  > The second patch has the explanation why Waldemar patch is not really
>>  > correct.  
>>
>> Ok. Can I take this as an acked-by for the check-bin-arch / pkg-generic
>> changes then? ;)
> 
> I haven't reviewed the implementation details, but on the general
> principles, yes, I'm OK. It's a bit annoying to extend the package
> infrastructure for such a specific case, but I don't really see a
> better solution here, except hacking libmpeg2 to remove the runtime
> detection logic.
> 
> On the other hand, do we care enough about libmpeg2 on SPARC to extend
> the package infrastructure just for this purpose? In the end, even if
> Waldemar's solution is not "correct", it avoids the need to extend the
> package infrastructure just for a purpose of a single package that will
> most likely never ever be used on SPARC.
> 
> Arnout, what do you think?

 When I spun that patch, I expected there would be more use cases than just
libmpeg2. But the autobuilders don't point to anything obvious, so perhaps not.

 I've marked as Rejected in patchwork. We can pick it up again if something else
turns up.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] libmpeg2: fix sparc32 build

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 >> Arnout, what do you think?

 >  When I spun that patch, I expected there would be more use cases than just
 > libmpeg2. But the autobuilders don't point to anything obvious, so perhaps not.

 >  I've marked as Rejected in patchwork. We can pick it up again if something else
 > turns up.

Ok, sounds sensible - Thanks!

-- 
Bye, Peter Korsgaard