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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
