On 05/16/10 16:04, Kern Sibbald wrote: > On Sunday 16 May 2010 19:25:04 Phil Stracchino wrote: >> Yes, it would definitely be a non-trivial project (and one requiring >> much more knowledge of autoconf than I have). I was quite taken back to >> discover how much of the configuration currently does not yield the >> expected results, and more so to discover that I could not build a fully >> static client on Linux at all. > > Well, you *can* build a static client. > > Just use the appropriate options. They are documented. I think the key > is --disable-libtool if I am not mistaken.
No, there's more to it than that. That's just the configuration issue: you must both use the --enable-static option and *explicitly* add disable-libtool. But there's a more serious problem beyond that. The major problem is that when building against a current glibc, the functions dlopen, initgroups, getgrdir, getgrnam, endgrent, getpwnam, getpwuid, endpwent, getaddrinfo, gethostbyname2, and getservbyname still require that the glibc dynamic link libraries *that the client was built against* be present in order for it to run. The resulting client is /de facto/ partially statically linked and partially dynamically linked. If you build a "static" Linux client, then try to execute it from a rescue CD environment that has a different minor version of glibc than the one the client was built against, the client will start up correctly and run, and will actually respond correctly to a "status client" and continue to run, but will SEGV as soon as you try to begin a restore. *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 have a suspicion this has to do with nsswitch and PAM issues, but it's only a theory at this point. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 [email protected] [email protected] [email protected] Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
