On Monday 17 May 2010 12:10:36 Martin Simmons wrote: > >>>>> On Mon, 17 May 2010 00:47:01 -0700, Kevin Keane said: > > > > Accept-Language: en-US > > Content-Language: en-US > > acceptlanguage: en-US > > > > > -----Original Message----- > > > From: James Harper [mailto:[email protected]] > > > Sent: Sunday, May 16, 2010 4:31 PM > > > To: Phil Stracchino; Kern Sibbald > > > Cc: [email protected] > > > Subject: Re: [Bacula-devel] Proposal: Revise configure options > > > > > > > *If you don't see the compile warnings*, there is no indication that > > > > > > you > > > > > > > haven't built a fully working static client ... until you try to use > > > > > > it > > > > > > > in a bare-metal-restore situation on a minimal rescue CD. On the > > > > > > system > > > > > > > you built it from, with the build glibc available, it will work > > > > > > perfectly. > > > > > > > > > I'm curious, what is the attraction of the static client these days? It > > > might have been an issue when people were using 2.88MB floppy disks and > > > had to run with the minimum possible configuration, but any DR media > > > these days has plenty of space for dynamic libraries, and will have > > > more than enough memory that a ramdisk isn't going to run out of > > > memory, so I wouldn't have thought it would be such a big deal anymore. > > > > It's not just the disk space. In fact, I'd argue that statically linked > > applications take up more, not less, space. > > > > 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. > > I'm puzzled by this because I have (non-Bacula) code linked with the glibc > shared library that runs fine on any linux from Red Hat 9 through to the > very latest releases of all major distros. > > The compatibility problems are usually caused by other libraries, not > glibc. > > If you try to link glibc statically but still have a few dynamic things > loaded with dlopen then that could cause problems like you describe, > because of dependencies between modules in the internals of glibc.
Martin, the biggest problem is that most people don't know how to find the libararies that are used by Bacula and get them loaded into a chroot environment that is necessary for *most* (or at least the most extreme) disaster recovery situations. Kern ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
