rtmpdump_2.2e-2_i386.changes ACCEPTED

[Reinhard Tartler]

On Thu, Jun 10, 2010 at 10:37:23 (CEST), Howard Chu wrote:

> Reinhard Tartler wrote:
>> Hi Howard,
>>
>> in our multimedia packaging team, there is some interest by various
>> people to use librtmp inside shared libraries like libavformat.so or
>> gstreamer modules.  This requires compiling the library as position
>> independent code (PIC).
>>
>> Would you consider a patch for building a shared library librtmp.so for
>> the next release?  This way we could have both a PIC and a non-PIC
>> version, and avoid code duplications across application packages. The
>> downside of this would be of course the (well known) overhead of shared
>> library maintenance.
>
> If you submit a patch I'll take a look. I'm not ready to go there yet
> myself, there are other loose ends that still need to be tied up first.

Thanks for this input. I guess we should stick with a static library for
now until we have some packages actually using librtmp.

>> Please share your thoughts on this topic with us :-)
>>
>> regards,
>>          Reinhard
>>
>> On Thu, Jun 10, 2010 at 09:46:07 (CEST), Fabian Greffrath wrote:
>>
>>> Hi all,
>>>
>>> Am 07.06.2010 11:50, schrieb Sebastian Dröge:
>>>> Or at least a -fPIC static library? :)
>
> Obviously this is what I recommend for now.
>
>>> given that upstream already has a rtmpsrc gstreamer-plugin in the "bad"
>>> set waiting (thanks slomo), I'd like to take action on this issue. My
>>> question is, how to do it best?
>>>
>>> 1) Build the library only once but with -fPIC. Does this have an effect
>>> on other non-library binaries linking against it? (If not, why don't we
>>> build all static libraries in Debian with -fPIC?)
>
> -fPIC code on most platforms is a little slower than non-PIC; that's the
> reason most systems don't build this way by default. Some notable
> exceptions I recall are AIX/POWER (all binaries are PIC) and M68K (PIC
> was actually more compact and faster in many cases). I think on modern
> systems the difference is negligible.
>
>>> 2) We build the library twice in debian/rules, once with and once
>>> without -fPIC.
>>> a) We rename the -fPIC variant to librtmp_pic.a and install it into
>>> librtmp-dev in addition the non-PIC library. (This would probably also
>>> require some patching against the pkg-config file.)
>>> b) Both variants will be called librtmp.a but installed into different
>>> packages librtmp-dev and libtrmp_pic-dev which conflict against each
>>> other. (This would require a separate pkg-config file for each variant.)
>
> Sounds like a lot of hassle for no real reason.

I guess we should go then with a), or c): don't provide a non-PIC .a
file at all.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4