[Freeswitch-dev] DSO library management issues

Roman Shaposhnik rvs at sun.com
Sat Sep 30 23:01:37 EDT 2006


On Sat, 2006-09-30 at 10:09 -0700, Anthony Minessale wrote:
> There are a few good explanations (I hope).

[ Good explanations skiped ]

  Ok. Well, in that case let me ask you this -- why do you
still want to keep this libraries as separate entities? From
what you've told me it seems that the best way for achiving
your goals would be to simply fold *all* of them into
lib subdirectory and just start treating them as parts
of FreeSwitch and not aliens. That would not only eliminate  
the need for 'wget' during the build process and also 
the need for endless separate ./configure ; make ; make install
sequences but will make it *much* easier to optimize 
FreeSwitch at a compiler level. 

> I am fairly concerned with making huge initiatives in the build
> process
> during a time where I am still coding 12 hours a day on the core but I
> am open
> to improvement as long as the tangent does not impeed my development
> effort.
> Imagine if someone wanted to install superior scafolding while the guy
> is on top of it building the house still.  Once development shifts to
> higher level
> stuff my concerns will most likely subside.

  Fair enough. But for performance tweaks this stuff matters. Now,
I would've completely understood the boundaries for my tweaks
had you have systems dependencies in mind. But from what you've
told me it looks like you really wouldn't mind privatizing all of these
libraries, would you ?

> I am truely anxious to see what happens on this super sun box
> and I'd like to thank you for your efforts and your valuable time I
> really
> appriciate your help.

  Thanks and I'll try to be helpful ;-)

Thanks,
Roman.

P.S. <compiler engineer hat on>
Now let me tell you -- DSOs used for dynamic *linking* are BAAAAD
(but don't confuse them with DSOs used for dynamic loading --
these are ok). So if there's any hope to get rid of them that
would help FreeSwitch on a couple of different levels starting
from stability and all the way up to performance.
</ompiler engineer hat off>




More information about the Freeswitch-dev mailing list