[Ffmpeg-devel] Shared Libraries

François Revol revol
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 
as that.
<off topic>
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 
full link).
</off topic>

> 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 
> which
> reads:
> 
> 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 
that:

rm -f libav*/libav*.for.ffdecoder.so
make -C libavcodec/ SLIBSUF=.for.ffdecoder.so SHFLAGS='-nostart -
Xlinker -soname=libavcodec.for.ffdecoder.so'
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 
> this
> 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
AVCLIBS+=-lavcodec$(LIBNAMEEXTRA) -L../libavcodec

That way you would just have to call make with LIBNAMEEXTRA=.mlt or 
.for.mlt

> 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 
> reason

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 
cvs.

(Any better name for that variable ?)

Fran?ois.






More information about the ffmpeg-devel mailing list