[LCP]Dynamic libraries and plugins

[Joachim Bauernberger]

Hi Paul,

On Tuesday 02 July 2002 01:53, Paul Gearon wrote:
> On Mon, 24 Jun 2002, Joachim Bauernberger wrote:
> 
> > I have a also a question regarding dlopen and friends (and when it 
would
> > make sense to use them)....
> > Say I have a program which is executed often (maybe even several 
times a
> > second) with many different options.
> > Due to soooo many options would it make sense to put different parts 
of
> > the code into seperate shared libs and call dlopen() by hand?
> > It would make the size of the binary smaller and many features which 
are
> > not needed are therefore never loaded no?
> > I specially think about saving initialization time of a program...
> 
> You won't gain much from this approach.  Firstly, the size of your 
program
> won't really change if you dynamically load by hand, as opposed to 
linking
> against a .so library (it might get a few bytes bigger, but there 
won't be
> any real change).

I see. 

> 
> Then, as soon as you call dlopen on the file the whole thing will get
> mapped into memory, just the same as if you let it be automatically 
loaded
> with the program.  So there isn't any real savings there.  About the 
only
> difference I can see is that you can delay the mapping of multiple
> libraries until later in the process.  So if you had a LOT of 
libraries to
> load then you'd see an effect.
> 

OK. 
But say I want to implement library dependant functionality that is only 
needed in certain execution paths. 
I.e. I have a MIME parsing utility which is to perform a certain amount 
of checks or maybe rewriting from one format to another, as well as 
virusscanning of attachments, etc ..... Now the utility will be 
executed on a server for every incoming mai. It is also responsible for 
delivering/forwarding the mail to the user. 
Now if I want to offer the virusscanning part to only a selected group 
of people I would still need to link the binary with the shared library 
.. In this case wouldn't my app benefit from only calling dlopen in 
case the user wants to scan that mail for virii?  
Also virusscanning is just an example there are more functionalities 
that I can think of that could be added that way.... 

> The best reason for dlopen and dlsym is to load from libraries which 
may
> or may not be there.  For instance, MPlayer (the multimedia video 
player)
> has a look at the file type and then tries to load the appropriate 
shared
> library, depending on what it found.  If it's DivX (MPEG-4/MP3)it 
loads
> one library, if it's MPEG-2/AC3 it loads another library, and so on.
> Then if it sees, say, an apple quicktime file it might find that the
> required library isn't there and exit.  If these libraries were not 
loaded
> with dlopen then the program wouldn't be able to start at all if it 
didn't
> see the quicktime library, even though you might be wanting to watch a
> DivX file and you don't care about quicktime.  Recently I wanted to 
watch
> an obscure file format, and MPlayer couldn't show it.  All I had to do 
was
> find the appropriate library file and put it where MPlayer could see 
it
> and it played fine.
> 
> (yes, I know that many of the libraries for MPlayer are not .so files, 
but
> the principle is the same, and MPlayer seemed like a good example to 
me)
> 
> Hope I've made sense here.  My brain hasn't kicked in yet this 
morning.

Thanks for the explanation.

Best Regards,
Joachim

> 
> Regards,
> Paul Gearon
> 
> Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
> immane mittam.
> (Translation from latin: "I have a catapult. Give me all the money,
> or I will fling an enormous rock at your head.")
> 
> 
> 
> _______________________________________________
> This is the Linux C Programming List
> :  http://lists.linux.org.au/listinfo/linuxcprogramming List
> 
> 

-- 
http://mXscan.org/pgp/joachim.html