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) > 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 ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
