[Freeswitch-dev] DSO library management issues

[Roman Shaposhnik]

On Sat, 2006-09-30 at 13:44 -0400, Michael Jerris wrote:
> Is there a way on *nix (gcc and sun
> studio at least) to optimize out these stub functions when statically
> linking so that we don't take a performance hit by doing this? 

  I don't think I really understand what your needs here are. Could
you give a couple of practical examples ?

> We have already run into
> quite a few issues with many different versions of for example apr on
> the same box, and we have in the past needed to add patches to some of
> these libs, which is why we have selected to build them in tree.

  That would be yet another reason to just go ahead and privatize them
inside FreeSwitch. That way you would be able to hide all of the symbols
you don't really need to export (which is quite good for performance
as well since it lets compiler do things like inter-module inlining
and such).

> My biggest
> concern on this one is colliding with other libraries installed on the
> system, which I think linking them statically will resolve, I am still
> not clear what the general dislike of this practice is about?  Is it
> build time?  Something else?

  I have a simple advice in this case -- just import all of the source
code you need into your own tree. Privatize it, yet make it easier
to apply changes you care to apply from the development versions
of the code you've imported (like don't change the names of files
or layout of subdirectories, clearly mark where the code came from
and what version was used, etc.). You see, the only advantage 
of depending on systems DSOs like sqlite.so, etc is that you
kind of save memory and disk. But memory and disk is really cheap
these days and I'd rather burn some memory in favor of getting 
lots of additional stability and performance. 
 
> >   2. As for the #3... my take on it is that we shouldn't really
> >   have #3 in FreeSwitch at all. Every single library from that
> >   category should either be moved to #1 or to #2. If it ends
> >   up being in #2 than it has to be moved to a separate SVN repo.
> 
> I don't entirely disagree on this one, it's more been just a matter of
> conveinience, even for the codec libs, if we don't start just using
> ffmpeg, I plan to make a distribution of these separately, for now,
> maybe learning to use svn externals is the best bet?

  If we just follow total privatization approach all of these
becomes moot. If we don't -- that's the smallest of the issues
anyway. Now as for ffmpeg -- the really cool thing about it
is that it really forces you into privatization approach. Hence
I'd just import the libavcodec en mass into an approriate 
plugin for the FreeSwitch.

> I am not sure there is any good way we could accomplish things like that
> if we don't build them on our own, at least from a developer point of
> view.  As for packaging, I keep leaning towards statically linking and
> not depending on other packages... if this is incredibly stupid for some
> reason other than size, I would need to be convinced, as it will greatly
> simplify so many other things.

  That is, pretty smart, in fact ;-) Now lets just convince Anthony ;-)

Thanks,
Roman.