Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
Am 07.06.2010 11:50, schrieb Sebastian Dröge: Or at least a -fPIC static library? :) Reinhard? I think the new ffmpeg 0.6 will also benefit from a -PIC librtmp, isn't it? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
On Thu, Jun 17, 2010 at 10:01:50 (CEST), Fabian Greffrath wrote: Am 07.06.2010 11:50, schrieb Sebastian Dröge: Or at least a -fPIC static library? :) Reinhard? I think the new ffmpeg 0.6 will also benefit from a -PIC librtmp, isn't it? indeed, but I don't remember what the consesus is. I propsed to just compile librtmp.a with -PIC, but I'm not sure if everyone agrees here? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
On Thu, 2010-06-17 at 10:49 +0200, Reinhard Tartler wrote: On Thu, Jun 17, 2010 at 10:01:50 (CEST), Fabian Greffrath wrote: Am 07.06.2010 11:50, schrieb Sebastian Dröge: Or at least a -fPIC static library? :) Reinhard? I think the new ffmpeg 0.6 will also benefit from a -PIC librtmp, isn't it? indeed, but I don't remember what the consesus is. I propsed to just compile librtmp.a with -PIC, but I'm not sure if everyone agrees here? You said previously that you prefer to wait for upstream to take the shared library patch. Upstream said, that compiling with -fPIC is what he suggests and that this will only cause very minor performance degrations (you need to do symbol relocation a single time per process or use prelink ;) ). IMHO we should simply build librtmp with -fPIC signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
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 pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
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. 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? :) 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 pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
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 pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
Am 10.06.2010 10:37, schrieb Howard Chu: 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. Here you go! From 34dd288920eaf70f4a6abcecf8a63c185b9912e6 Mon Sep 17 00:00:00 2001 From: Fabian Greffrath fab...@greffrath.com Date: Thu, 10 Jun 2010 11:22:54 +0200 Subject: [PATCH] Build a shared library. --- librtmp/Makefile | 36 +++- 1 files changed, 31 insertions(+), 5 deletions(-) diff --git a/librtmp/Makefile b/librtmp/Makefile index 88fd611..bc5b939 100644 --- a/librtmp/Makefile +++ b/librtmp/Makefile @@ -28,12 +28,17 @@ INCDIR=$(DESTDIR)$(incdir) LIBDIR=$(DESTDIR)$(libdir) MANDIR=$(DESTDIR)$(mandir) -all: librtmp.a +LIBRARY=librtmp.a +LIBRARY_SO=librtmp.so +LIBRARY_SO_VER=librtmp.so.0 + +all: $(LIBRARY) $(LIBRARY_SO) clean: - rm -f *.o *.a + rm -f *.a *.lo *.o *.so *.so.* -librtmp.a: rtmp.o log.o amf.o hashswf.o parseurl.o +# Static library +$(LIBRARY): rtmp.o log.o amf.o hashswf.o parseurl.o $(AR) rs $@ $? log.o: log.c log.h Makefile @@ -42,13 +47,34 @@ amf.o: amf.c amf.h bytes.h log.h Makefile hashswf.o: hashswf.c http.h rtmp.h rtmp_sys.h Makefile parseurl.o: parseurl.c rtmp.h rtmp_sys.h log.h Makefile +%.o: %.c + $(CC) $(CFLAGS) -o $@ -c $ + +# shared library +$(LIBRARY_SO_VER): rtmp.lo log.lo amf.lo hashswf.lo parseurl.lo + $(CC) -shared -Wl,-soname,$@ $(LDFLAGS) -o $@ $? + +$(LIBRARY_SO): $(LIBRARY_SO_VER) + ln -sf $? $@ + +log.lo: log.c log.h Makefile +rtmp.lo: rtmp.c rtmp.h rtmp_sys.h handshake.h dh.h log.h amf.h Makefile +amf.lo: amf.c amf.h bytes.h log.h Makefile +hashswf.lo: hashswf.c http.h rtmp.h rtmp_sys.h Makefile +parseurl.lo: parseurl.c rtmp.h rtmp_sys.h log.h Makefile + +%.lo: %.c + $(CC) $(CFLAGS) -fPIC -o $@ -c $ + librtmp.pc: librtmp.pc.in Makefile sed -e s;@prefix@;$(prefix); -e s;@VERSION@;$(VERSION); \ -e s;@CRYPTO_REQ@;$(CRYPTO_REQ); librtmp.pc.in $@ -install: librtmp.a librtmp.pc +install: $(LIBRARY) $(LIBRARY_SO) librtmp.pc -mkdir -p $(INCDIR) $(LIBDIR)/pkgconfig $(MANDIR)/man3 cp amf.h http.h log.h rtmp.h $(INCDIR) - cp librtmp.a $(LIBDIR) + cp $(LIBRARY) $(LIBDIR) + cp $(LIBRARY_SO) $(LIBDIR) + cp $(LIBRARY_SO_VER) $(LIBDIR) cp librtmp.pc $(LIBDIR)/pkgconfig cp librtmp.3 $(MANDIR)/man3 -- 1.7.1 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: rtmpdump_2.2e-2_i386.changes ACCEPTED
Am 05.06.2010 12:02, schrieb Archive Administrator: librtmp-dev_2.2e-2_i386.deb to main/r/rtmpdump/librtmp-dev_2.2e-2_i386.deb I can has shared lib KTHXBYE? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
