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
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? :)
> 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?)
> 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.)
> 3) We build the library twice, but patch upstream's Makefile to do so.
> Any more ideas?
> - Fabian
> pkg-multimedia-maintainers mailing list
Reinhard Tartler, KeyID 945348A4
pkg-multimedia-maintainers mailing list