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 _______________________________________________ pkg-multimedia-maintainers mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers