>>>>> 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 ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
