Reinhard Tartler schrieb:
In the end I think we should disable 005_runtime_cpudetect.diff. It is 2
years old, and its purpose is to "fix" runtime cpu detection on m68k and
i386. Runtime CPU detection isn't really favored upstream, see
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-March/043886.html
and the resulting thread here.
Allright, on patch less that diverges us from upstream.
However, a doable solution has been proposed here. lu_zero, the gentoo
ffmpeg maintainer suggested that we should install an altivec disabled
libavcodec in /usr/lib and an altivec enabled version in
/usr/lib/altivec. First very simple tests show the expected result.
Erm, does any other package in Debian do it this way? Is this even FHS
compliant? Will altivec systems know where to find 'their' libs or
will there be other magic involved?
In any case, I think I will work on reorganising the debian/rules build
target to ease building different flavors, at best in paralell. I intend
to do so to copy (using `cp -rl`) the ffmpeg source in build directories
('build/$flavor') and build there.
Well, allright. This sounds complicated but seems to be the cleanest
solution to provide all possible sets of optimized and unoptimized
libraries for all supported architectures.
Furthermore this leads to maintaining
a build matrix for the following flavors:
- static
- dynamic, noopt
- dynamic, MMX (amd64, i386)
- dynamic, altivec (powerpc)
- dynamic, VIS (sparc)
and so on.
May I assume that packages like gstreamer0.10-ffmpeg depend on
'dynamic, noopt' in the first place and that other, optizmized library
packages may be installed additionally or as a replacement on
architectures that support it? If it is possible at all, why don't we
provide non-altivec shared libs by now?
--
Dipl.-Phys. Fabian Greffrath
Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum
Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail: [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
