Re: [libdv-dev] Lib status of libdv.

[Daniel K. <ko...@ta...>]

[Replying to a really ancient mail.]

On Tue, Nov 21, 2000 at 01:37:22PM -0800, Charles 'Buck' Krasic wrote:
> Building as a shared lib shouldn't be a big deal.  I'd had a bad
> experience with the autotools around the time we started libdv, so I
> decided to stick with plain Makefile.  It probably wouldn't be a big
> deal to convert to autotools.

I've tried to compile a sane Debian package of libdv for some time now,
and actually building libdv as a shared lib turns out to be quite a
problem, at least as far as the optimised versions are concerned. That's
because the asm routines are not coded to be relocatable. Changing this
basically involves sacrificing a register to the global offset table
and changing every reference to objects in the .data section when=20
__PIC__ is defined.

In detail, it appears that quant_x86.S transpose_x86.S are already fine
because they do not contain .data sections. dct_block_mmx.S, encode_x86.S,=
=20
idct_block_mmx.S appear to be trivially fixable, which leaves
rgbtoyuv.S and vlc_x86.S as the hard cases. Both make heavy uses of
registers and local data alike. Therefore, a straightforward approach
to code them relocatable might well affect performance in the static
case, too. The alternative being two completely seperate version for static=
=20
and shared linkage. What's your opinion on this? Do you consider it
worthwhile for libdv to be available as a shared lib at all?

Regards,

Daniel.

--=20
	GNU/Linux Audio Mechanics - http://www.glame.de
              Cutting Edge Office - http://www.c10a02.de
	      GPG Key ID 89BF7E2B - http://www.keyserver.net