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 :-)
>> 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.
Reinhard Tartler, KeyID 945348A4
pkg-multimedia-maintainers mailing list