On Monday 17 May 2010 11:08:17 James Harper wrote: > > It's not just the disk space. In fact, I'd argue that statically > > linked > > > applications take up more, not less, space. > > That's only true if you have multiple statically linked applications > that include the same code. But if you had a single app, guess which of > 'statically linked app' and 'dynamically linked app + all required > libraries' is going to be smaller. > > > A far more important issue is the one Phil pointed out: you also need > > to have > > > the exactly correct version of the runtime libraries available. When > > you are > > > in a rescue situation (by definition strapped for time), you don't > > want to > > > find bacula requires a different glibc than the one the rescue CD has. > > Having > > > a statically linked one will all but guarantee that it will actually > > run when > > > you need it how you need it, even if you booted off a different Linux > > version. > > > If you haven't got a rescue cd with the stuff you need on it then you're > already in trouble... but having said that you are right that there are > situations where a static lib would make things easier though (eg your > old hardware broke and you've been able to find new hardware but it's > too new for the kernel on your boot cd). Would a chroot environment with > all the required libraries work? (aside from talking up even more memory > and disk space that is).
Right on James. While it is true that a statically linked FD simplifies the disaster recovery situation a bit, I think most people are missing the important point that you are making here. When one does a recovery, you boot some Linux, certainly, but typically in a recovery situation, one is in a chroot environment with an empty disk. Consequently, it is really quite easy (if you know how) to load all the shared objects that were linked with a dynamically linked FD. The issue has much less to do with disk space than convenience for a statically linked FD or a bit more complication for a dynamically linked version. Kern ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
