mplayer2 FTBFS on sparc

[Reinhard Tartler]

On So, Okt 09, 2011 at 15:45:07 (CEST), Jurij Smakov wrote:

> On Sun, Oct 09, 2011 at 10:03:47AM +0200, Reinhard Tartler wrote:
>> On Sa, Okt 08, 2011 at 19:34:47 (CEST), Jurij Smakov wrote:
>> 
>> > On Sat, Oct 08, 2011 at 06:51:49PM +0200, Kurt Roeckx wrote:
>> >> On Sat, Oct 08, 2011 at 03:21:50PM +0200, Reinhard Tartler wrote:
>> >> > Hi,
>> >> > 
>> >> > I've noticed that mplayer2 2.0-134-g84d8671-7 failed to build on sparc,
>> >> > and I'm quite puzzled why. There are no code changes compared to
>> >> > 2.0-134-g84d8671-6, which did build on the very same buildd 'lebrun':
>> >> > 
>> >> > https://buildd.debian.org/status/logs.php?pkg=mplayer2&arch=sparc
>> >> > 
>> >> > Could anyone please have a look and explain me what's going on? Is there
>> >> > anything to fix in the package? (porters CC'ed with this mail).
>> >> 
>> >> -7 was build with binutils_2.21.53.20110922-1, gcc-4.6_4.6.1-13, dpkg-dev_1.16.1
>> >> -6 was build with binutils_2.21.53.20110805-1, gcc-4.6_4.6.1-7, dpkg-dev_1.16.0.3
>> >> 
>> >> I suspect that one of those changes broke it for you.
>> >
>> > As I mentioned to Reinhard on irc (not sure whether he noticed), this 
>> > commit looks suspicious, as it introduces the "hardware compatibility" 
>> > error message, seen during failed build:
>> >
>> > http://repo.or.cz/w/binutils.git/commitdiff/24f272de258d79c9d959143a8fd626b9961a8ac0
>> 
>> I did but had to leave from irc.
>> 
>> Funny thing, a manual build in sperger's sid chroot did succeed. I used:
>> 
>> binutils (2.21.90.20111004-1)
>> gcc-4.6 (4.6.1-13)
>> dpkg (1.16.1)
>
> Do you have the logs from the sperger build?

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?

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 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.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4