[Ffmpeg-devel] Shared Libraries
Mon May 2 22:48:41 CEST 2005
> Hi all,
> I am definitely not wanting to start a flamewar regarding the use of
> shared objects as I'm well aware of the policy regarding this.
> However, I am just wondering if there is a particular reason why
> libavformat.so links with libavcodec.so?
Because libavformat requires symbols from libavcodec.
Not all OS can handle undefined symbols at link time.
Linux can, but BeOS can't for ex.
So since lavf depends on lavc, lavf must link to lavc, it's as simple
allowing undefined symbols is dangerous, will hide mistakes in builds
and in design. It is bad design to not resolve all symbols and have
circular dependancies (those you can easily not see if you don't do a
> So my work around is this - I have a private instance of ffmpeg and
> instead of installing libavformat.so and libavcodec.so directly, I
> install libmltavformat.so and libmltavcodec.so and link my wrapper to
> these (thus, if the user installs normally from cvs or a release
> version, there's no clash).
> But this fails simply because of the line in libavformat/Makefile
> AVCLIBS+=-lavcodec -L../libavcodec
> With this line in place, my version of libmltavformat.so needs
> libavcodec.so, so it doesn't matter how I install and link them (at
> least on linux).
> When I remove this, I can safely install the files as I need.
I have the same problem with FFDecoders, and soemthing else I've been
working on, because I also want it not to break if someone updates the
lib I build them with different names. Since I don't do that often, and
I don't have ffmpeg cvs in a bigger build process I use a script to do
rm -f libav*/libav*.for.ffdecoder.so
make -C libavcodec/ SLIBSUF=.for.ffdecoder.so SHFLAGS='-nostart -
make -C libavformat/ SLIBSUF=.for.ffdecoder.so SHFLAGS='-nostart -
Xlinker -soname=libavformat.for.ffdecoder.so' AVCLIBS+='-
lavcodec.for.ffdecoder -L../libavcodec -lmp3lame'
A bit crude but it does the job.
> My feeling is that a distributor could use this approach to create a
> stable package which isn't going to break anything else... Taking
> this a
> step further, they could even build a larger suite which also share
> particular build.
I'd think we could do a bit as I did but splitting SLIBSUFF, that is
have the libs named libavcodec$(LIBNAMEEXTRA)$(SLIBSUFF), and the
LDFLAG for lavf would be
That way you would just have to call make with LIBNAMEEXTRA=.mlt or
> If need be, I'll just apply a patch to remove this line prior to the
> build and all will be well on my test system, but maybe there's a
As I said it's there because it must be there for consistency and to
make sure it builds on every platform.
> it's there (other than the obvious 'it simplifies linking with
It just makes it work :p
I'll have a look at that when I get some more time.
feel free to send a patch implementing that LIBNAMEEXTRA stuff,
it will save me some time and I'll just have to check it and put it in
(Any better name for that variable ?)
More information about the ffmpeg-devel