After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 105242 - build ffmpeg libs as shared libs
build ffmpeg libs as shared libs
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.6.0
Other other
: Normal major
: 0.6.x
Assigned To: Thomas Vander Stichele
GStreamer Maintainers
: 105933 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-02-04 22:17 UTC by David I. Lehn
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
build and use ffmpeg's libavcodec as a shared lib (2.35 KB, patch)
2003-02-04 22:20 UTC, David I. Lehn
none Details | Review
gst-libs/ext/ffmpeg/configure.gnu needed for shared libavcodec patch (54 bytes, text/plain)
2003-02-04 22:21 UTC, David I. Lehn
  Details
patch to gst-libs/ext/ffmpeg (4.49 KB, patch)
2003-08-12 07:23 UTC, David Schleef
none Details | Review
patch to appy in ffmpeg dirctory (4.49 KB, patch)
2003-08-22 21:39 UTC, David Schleef
none Details | Review

Description David I. Lehn 2003-02-04 22:17:53 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.
Comment 1 David I. Lehn 2003-02-04 22:20:43 UTC
Created attachment 14104 [details] [review]
build and use ffmpeg's libavcodec as a shared lib
Comment 2 David I. Lehn 2003-02-04 22:21:57 UTC
Created attachment 14105 [details]
gst-libs/ext/ffmpeg/configure.gnu needed for shared libavcodec patch
Comment 3 David Schleef 2003-04-04 22:07:10 UTC
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.
Comment 4 David Schleef 2003-04-05 21:13:03 UTC
HEAD + patch builds on powerpc.
Comment 5 Thomas Vander Stichele 2003-05-11 17:42:19 UTC
if we build libavcodec.so as a shared lib, where would you install
that lib on the system ?
Comment 6 Christian Fredrik Kalager Schaller 2003-05-12 13:08:42 UTC
Assigning to thomasvs, but probably post 0.6.2 material
Comment 7 David Schleef 2003-05-13 04:41:21 UTC
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.)
Comment 8 David Schleef 2003-08-12 07:21:51 UTC
*** Bug 105933 has been marked as a duplicate of this bug. ***
Comment 9 David Schleef 2003-08-12 07:23:28 UTC
Created attachment 19138 [details] [review]
patch to gst-libs/ext/ffmpeg
Comment 10 David Schleef 2003-08-12 07:28:51 UTC
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?
Comment 11 David Schleef 2003-08-22 21:39:56 UTC
Created attachment 19460 [details] [review]
patch to appy in ffmpeg dirctory
Comment 12 David Schleef 2003-09-11 20:23:20 UTC
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.
Comment 13 David Schleef 2003-12-02 01:50:40 UTC
This is not going to be backported.