GNOME Bugzilla – Bug 105242
build ffmpeg libs as shared libs
Last modified: 2004-12-22 21:47:04 UTC
From Bug#104208: "I was thinking this is a problem of ffmpeg libs not being built shared. Right now the ffmpeg plugin links to ibavcodec.a and libavformat.a. I think the theory is that we have to change the build so that ffmpeg's configure script is called with --enable-shared. I did this and can provide the patch but I'm not sure it matters. ffmpeg only builds libavcodec.so not libavformat.so. Just fixing one of the libs probably isn't enough. Plus if you look at the ffmpeg build scripts it's not like it even bothers to use the flag to do -fPIC. This is ok on x86 but not many other archs. It looks like the solution may be to work on the ffmpeg build so it uses the BUILD_SHARED flag to use -fPIC and build shared lib for libavformat too. Yuck." Attached is a partial patch. This will build libavcodec as a shared lib. However, libavformat is still setup to build as a static lib. Further work is needed to build that shared too.
Created attachment 14104 [details] [review] build and use ffmpeg's libavcodec as a shared lib
Created attachment 14105 [details] gst-libs/ext/ffmpeg/configure.gnu needed for shared libavcodec patch
I recommend applying this patch. ffmpeg doesn't build except on i386 and powerpc anyway. If someone reminds me, I'll check the powerpc build with this patch applied. This should also be a 0.6.1 targer, imo.
HEAD + patch builds on powerpc.
if we build libavcodec.so as a shared lib, where would you install that lib on the system ?
Assigning to thomasvs, but probably post 0.6.2 material
Put the lib in /usr/lib/gstreamer-0.6/, as it's private to gstreamer. Or better, link the plugin directly to a PIC version of the .a library. (No, I don't know how to do that.)
*** Bug 105933 has been marked as a duplicate of this bug. ***
Created attachment 19138 [details] [review] patch to gst-libs/ext/ffmpeg
Attached is an idea for a new automake-based build system for ffmpeg in HEAD. I think it does most of what we want it to do, and builds shared libs. Minor (obvious) changes are needed to the plugin's Makefile.am. In addition, there's some bogus asm in ffmpeg that doesn't compile if -fPIC is turned on. I don't have a patch for that, because sf is being a bastard. Testing is minimal. Basically, just nm'ing the plugin to see that there are no undefined symbols. The big question is, do we want to support this kind of hackery when we update the ffmpeg snapshot?
Created attachment 19460 [details] [review] patch to appy in ffmpeg dirctory
Checked in to HEAD. It's not trivial to backport, and would take about the same amount of time to make sure things are compiled correctly. I recommend holding off on a backport until problems are dealt with in HEAD.
This is not going to be backported.