mplayer2 FTBFS on sparc

[Jurij Smakov]

On Sun, Oct 09, 2011 at 07:49:04PM +0200, Reinhard Tartler wrote:
> 
> I've copied it here:
> http://people.debian.org/~siretart/tmp/mplayer2_2.0-134-g84d8671-6_sparc.build
> 
> > I think the problem is that mplayer2 build system does CPU type
> > autodetection. The failed build used -mcpu=v8, however if I run it on
> > my machine (SunBlade 1000), I see that it compiles with
> > -mcpu=ultrasparc. If compilation on sperger used -mcpu=ultrasparc as
> > well, then it does not tell us anything, and it will fail again on
> > buildds.
> 
> Well spotted, you are totally right, sperger used '-mcpu=ultrasparc'.
> 
> > It looks like -mcpu=ultrasparc should always be used, because we do 
> > not support earlier machines anymore. For example, our system binaries 
> > report:
> >
> > jurij at debian:~/mplayer/mplayer2-2.0-134-g84d8671$ file /bin/ls
> > /bin/ls: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 
> > 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, 
> > BuildID[sha1]=0xdef701c1cd7c87aa36fb4955a5cd430e9f2bd1d1, stripped
> >
> > which is what is produced when -mcpu=ultrasparc is used. With -mcpu=v8 
> > one gets:
> >
> > jurij at debian:~/mplayer/mplayer2-2.0-134-g84d8671$ file mixer.o 
> > mixer.o: ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV), not stripped
> >
> > I think the right way to fix it is to turn off (possibly broken) CPU 
> > type autodetection and always use -mcpu=ultrasparc.
> 
> Upon inspecting the upstream configure script further, I think I now
> understand (more) what's going on. The configure script checks with
> uname -a the architecture, and enables vis and ultrasparc if it finds
> 'sparc64'. And indeed, sperger fails in the same way if I build with
> 'linux32', exactly like on the buildd.
> 
> Which still leaves us with the observation that the mentioned change in
> binutils broke the package build. Further inspection of the patch made
> my find the following 'workaround': When I pass this to configure:
> 
>   --extra-cflags='-Wa,-Av8'
> 
> then this flag is added to the compiler flags. And indeed, this unbreaks
> the compilation, now even with -mcpu=v8. I wonder why gcc doesn't pass
> it on his own behalf?

I've filed a bug against binutils (http://bugs.debian.org/644856)
 
> So, how do we proceed from here? I think I'll upload this change, but to
> me it seems that this is only a workaround and not a real fix. Moreover,
> Jurij suggests that mplayer2 should be compiled with -mcpu=ultrasparc
> anyway. The upstream configure script will do that when running under a
> 64bit kernel. However, this piece of information is 'hidden' on the
> buildds by the use of linux32.

I thought about it, and I don't really see why we would keep the 
linux32 wrapper on the buildds. It made sense in the past, when we 
supported sparc32 and really wanted to guarantee that if a package 
has CPU type autodetection, we would get the code which works on both 
sparc32 and sparc64 machines. These days it probably just leads to a 
ton of unnecessarily-unoptimized binaries in the archive.

> I personally don't have a sparc machine, nor the time or enough
> knowledge to drive this further. My main concern is to have mplayer2 in
> testing, which my change fulfills. Dear sparc porters, please advise,
> ideally in form of patches, how to improve the mplayer2 package. I'm
> pretty sure the patches would also apply to the mplayer package.

Best regards,
-- 
Jurij Smakov                                           jurij at wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC