[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

sparc32 and sparc64-only packages


Recently I've been investigating the xine-lib build failure on sparc. It turned out that failure occured due to libavcodec, shipped as a part of xine-lib, using the sparc64-specific assembler instructions in some routines (without providing any generic arch-independent replacement for them). So, the simplest solution is to add something like -mcpu=ultrasparc, which fixes the build failure, but renders xine-lib unusable on sparc32 machine. It turns out that there are at least a few binaries already in the archive (like binaries built from ffmpeg and mpeg2dec source packages) which uses -mcpu=ultrasparc. Those will not work on sparc32 either.

Hence the question: what does release team thinks about presence of such packages in the archive? Porting them to sparc32 may constitute a significant effort, not justified, in my opinion, by the benefit provided. sparc32 is not exactly geared for watching movies, and so far I can recall only one person on the debian-sparc list mentioning attempts to run xorg on it (current xorg lacks drivers for cards found on sparc32 boxes, they have been uploaded only recently and are currently in NEW). So, if sparc
at some point becomes a release candidate, would presence of the packages
only supporting sparc64 would be considered RC?

If someone would volunteer to look into these problems and produce the generic versions for the sparc64-optimized routines, such an effort would, of course, be very welcome.

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

Reply to: