[Buildroot] [PATCH 1/3] package/mplayer: disable inline sse on i386

[Buildroot] [PATCH 1/3] package/mplayer: disable inline sse on i386

[Bernd Kuhls]

Fixes

libavcodec/x86/ac3dsp_init.c: In function 'ac3_downmix_sse':
libavcodec/x86/ac3dsp_init.c:161:9: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
libavcodec/x86/ac3dsp_init.c:165:9: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
libavcodec/x86/ac3dsp_init.c:161:9: error: 'asm' operand has impossible constraints
libavcodec/x86/ac3dsp_init.c:165:9: error: 'asm' operand has impossible constraints
libavcodec/x86/ac3dsp_init.c:174:9: error: 'asm' operand has impossible constraints

found by autobuilder job
http://autobuild.buildroot.net/results/9f5/9f5a497c6242860fb67a5aa2996c3509f49a4564//

Please note that this patch alone will not fix all build errors, sse2
and mmxext show similar errors and are fixed by follow-up patches.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
 package/mplayer/mplayer.mk | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/package/mplayer/mplayer.mk b/package/mplayer/mplayer.mk
index f43ec5dc7..0d3ba0b81 100644
--- a/package/mplayer/mplayer.mk
+++ b/package/mplayer/mplayer.mk
@@ -292,6 +292,10 @@ define MPLAYER_DISABLE_INLINE_ASM
 		$(@D)/config.h
 	$(SED) 's,#define HAVE_MMX_EXTERNAL 1,#define HAVE_MMX_EXTERNAL 0,g' \
 		$(@D)/config.h
+	$(SED) 's,#define HAVE_SSE_INLINE 1,#define HAVE_SSE_INLINE 0,g' \
+		$(@D)/config.h
+	$(SED) 's,#define HAVE_SSE_EXTERNAL 1,#define HAVE_SSE_EXTERNAL 0,g' \
+		$(@D)/config.h
 endef
 
 ifeq ($(BR2_i386),y)
-- 
2.11.0

[Buildroot] [PATCH 2/3] package/mplayer: disable inline sse2 on i386

[Bernd Kuhls]

Fixes subsequent sse2-related build error

libavcodec/x86/cavsdsp.c: In function 'ff_cavsdsp_init_x86':
libavcodec/x86/cavsdsp.c:589:45: error: 'put_cavs_qpel16_mc00_sse2' undeclared (first use in this function)
libavcodec/x86/cavsdsp.c:589:45: note: each undeclared identifier is reported only once for each function it appears in
libavcodec/x86/cavsdsp.c:590:45: error: 'avg_cavs_qpel16_mc00_sse2' undeclared (first use in this function)
common.mak:60: recipe for target 'libavcodec/x86/cavsdsp.o' failed

after disabling inline sse by the previous patch.

Found while fixing autobuilder
http://autobuild.buildroot.net/results/9f5/9f5a497c6242860fb67a5aa2996c3509f49a4564/

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
 package/mplayer/mplayer.mk | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/package/mplayer/mplayer.mk b/package/mplayer/mplayer.mk
index 0d3ba0b81..59e37d828 100644
--- a/package/mplayer/mplayer.mk
+++ b/package/mplayer/mplayer.mk
@@ -296,6 +296,10 @@ define MPLAYER_DISABLE_INLINE_ASM
 		$(@D)/config.h
 	$(SED) 's,#define HAVE_SSE_EXTERNAL 1,#define HAVE_SSE_EXTERNAL 0,g' \
 		$(@D)/config.h
+	$(SED) 's,#define HAVE_SSE2_INLINE 1,#define HAVE_SSE2_INLINE 0,g' \
+		$(@D)/config.h
+	$(SED) 's,#define HAVE_SSE2_EXTERNAL 1,#define HAVE_SSE2_EXTERNAL 0,g' \
+		$(@D)/config.h
 endef
 
 ifeq ($(BR2_i386),y)
-- 
2.11.0

[Buildroot] [PATCH 3/3] package/mplayer: disable inline mmxext on i386

[Bernd Kuhls]

Fixes subsequent mmxext-related build error

libavcodec/x86/fdct.c: In function 'ff_fdct_mmxext':
libavcodec/x86/fdct.c:567:27: error: 'tab_frw_01234567' undeclared (first use in this function)
libavcodec/x86/fdct.c:567:27: note: each undeclared identifier is reported only once for each function it appears in
common.mak:60: recipe for target 'libavcodec/x86/fdct.o' failed

after disabling inline sse & sse2 by the previous patches.

Finally fixes
http://autobuild.buildroot.net/results/9f5/9f5a497c6242860fb67a5aa2996c3509f49a4564/

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
 package/mplayer/mplayer.mk | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/package/mplayer/mplayer.mk b/package/mplayer/mplayer.mk
index 59e37d828..73cfdde23 100644
--- a/package/mplayer/mplayer.mk
+++ b/package/mplayer/mplayer.mk
@@ -292,6 +292,10 @@ define MPLAYER_DISABLE_INLINE_ASM
 		$(@D)/config.h
 	$(SED) 's,#define HAVE_MMX_EXTERNAL 1,#define HAVE_MMX_EXTERNAL 0,g' \
 		$(@D)/config.h
+	$(SED) 's,#define HAVE_MMXEXT_INLINE 1,#define HAVE_MMXEXT_INLINE 0,g' \
+		$(@D)/config.h
+	$(SED) 's,#define HAVE_MMXEXT_EXTERNAL 1,#define HAVE_MMXEXT_EXTERNAL 0,g' \
+		$(@D)/config.h
 	$(SED) 's,#define HAVE_SSE_INLINE 1,#define HAVE_SSE_INLINE 0,g' \
 		$(@D)/config.h
 	$(SED) 's,#define HAVE_SSE_EXTERNAL 1,#define HAVE_SSE_EXTERNAL 0,g' \
-- 
2.11.0

[Buildroot] [PATCH 1/3] package/mplayer: disable inline sse on i386

[Thomas Petazzoni]

Hello,

On Sat, 13 May 2017 17:09:16 +0200, Bernd Kuhls wrote:
> Fixes
> 
> libavcodec/x86/ac3dsp_init.c: In function 'ac3_downmix_sse':
> libavcodec/x86/ac3dsp_init.c:161:9: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
> libavcodec/x86/ac3dsp_init.c:165:9: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
> libavcodec/x86/ac3dsp_init.c:161:9: error: 'asm' operand has impossible constraints
> libavcodec/x86/ac3dsp_init.c:165:9: error: 'asm' operand has impossible constraints
> libavcodec/x86/ac3dsp_init.c:174:9: error: 'asm' operand has impossible constraints
> 
> found by autobuilder job
> http://autobuild.buildroot.net/results/9f5/9f5a497c6242860fb67a5aa2996c3509f49a4564//
> 
> Please note that this patch alone will not fix all build errors, sse2
> and mmxext show similar errors and are fixed by follow-up patches.

All of this is very messy. Why isn't the ffmpeg code building properly
on x86 ? It's a major platform, shouldn't x86 just work ?

Best regards,

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

[Buildroot] [PATCH 1/3] package/mplayer: disable inline sse on i386

[Bernd Kuhls]

[posted and mailed]

Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
@public.gmane.org> wrote in news:20170514160855.2dea324b at free-electrons.com:

> All of this is very messy. Why isn't the ffmpeg code building properly
> on x86 ? It's a major platform, shouldn't x86 just work ?

Hi Thomas,

honestly I have no idea what causes the problem. Maybe activating inline asm 
on x86 at all is a problem due to hardware constraints as described here: 
http://stackoverflow.com/questions/8275859/error-cant-find-a-register-in-
class-general-regs-while-reloading-asm ?

Regards, Bernd

[Buildroot] [PATCH 1/3] package/mplayer: disable inline sse on i386

[Arnout Vandecappelle]

 Hi Bernd,

 Coming back to this ancient series...

On 15-05-17 22:38, Bernd Kuhls wrote:
> [posted and mailed]
> 
> Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
> @public.gmane.org> wrote in news:20170514160855.2dea324b at free-electrons.com:
> 
>> All of this is very messy. Why isn't the ffmpeg code building properly
>> on x86 ? It's a major platform, shouldn't x86 just work ?
> 
> Hi Thomas,
> 
> honestly I have no idea what causes the problem. Maybe activating inline asm 
> on x86 at all is a problem due to hardware constraints as described here: 
> http://stackoverflow.com/questions/8275859/error-cant-find-a-register-in-
> class-general-regs-while-reloading-asm ?


 Looking at current mplayer build failures, they seem slightly different than
the errors you report in the three patches here.

 With all the fixes we need for mplayer's bundled ffmpeg, why don't we just
switch to ffmpeg itself? mplayer upstream doesn't seem to advise against it,
Debian doesn't use the bundled one, so why not? OK, it will probably be some
effort to unbundle it, but I think it's more future-safe that way.

 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 1/3] package/mplayer: disable inline sse on i386

[Peter Korsgaard]

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

Hi,

 >  Looking at current mplayer build failures, they seem slightly different than
 > the errors you report in the three patches here.

 >  With all the fixes we need for mplayer's bundled ffmpeg, why don't we just
 > switch to ffmpeg itself? mplayer upstream doesn't seem to advise against it,
 > Debian doesn't use the bundled one, so why not? OK, it will probably be some
 > effort to unbundle it, but I think it's more future-safe that way.

Or alternatively drop mplayer now that we have mpv. Mplayer upstream
seems pretty dead with no releases in the last two years.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/3] package/mplayer: disable inline sse on i386

[Bernd Kuhls]

Am Sun, 01 Apr 2018 14:17:48 +0200 schrieb Peter Korsgaard:

> Or alternatively drop mplayer now that we have mpv. Mplayer upstream
> seems pretty dead with no releases in the last two years.

Hi Peter,

no objections, and I have no interest in fixing the ffmpeg code in 
mplayer. The only package selecting mplayer (as runtime dependency) is 
tovid, we need to handle that as well.
The libplayer package only has an optional dependency to mplayer, its 
option BR2_PACKAGE_LIBPLAYER_MPLAYER would need legacy handling.

Shall I send patches to remove mplayer?

Regards, Bernd

[Buildroot] [PATCH 1/3] package/mplayer: disable inline sse on i386

[Peter Korsgaard]

>>>>> "Bernd" == Bernd Kuhls <bernd.kuhls@t-online.de> writes:

 > Am Sun, 01 Apr 2018 14:17:48 +0200 schrieb Peter Korsgaard:
 >> Or alternatively drop mplayer now that we have mpv. Mplayer upstream
 >> seems pretty dead with no releases in the last two years.

 > Hi Peter,

 > no objections, and I have no interest in fixing the ffmpeg code in 
 > mplayer. The only package selecting mplayer (as runtime dependency) is 
 > tovid, we need to handle that as well.

Yes. It looks like tovid can use mpv as well, so that might be a
solution.

 > The libplayer package only has an optional dependency to mplayer, its 
 > option BR2_PACKAGE_LIBPLAYER_MPLAYER would need legacy handling.

Correct.

 > Shall I send patches to remove mplayer?

Yes, please!

-- 
Bye, Peter Korsgaard