Re: mplayer2 FTBFS on sparc
On So, Okt 09, 2011 at 21:05:56 (CEST), Jurij Smakov wrote:
> 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@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@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)
Thanks, the description seems pretty accurate to me.
>> 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.
Indeed, please notify me (e.g., with a wishlist bugreport) when the
buildds get changed, because I have to revert this change then:
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mplayer2.git;a=commit;h=992bf949037d0fafb69e87cbcc57393e528ef265
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Reply to: