sparc32 and sparc64-only packages
Hi,
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: