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.