How to link radiusd statically?

[Kenneth Marshall]

On Tue, Aug 05, 2008 at 04:40:05PM +0200, Alan DeKok wrote:
> abhay at clearcrypt.com wrote:
> > I would like to build radiusd with all necessary libraries statically linked
> > in. I have tried the following command
> > 
> > ./configure --enable-shared=no --enable-static=yes
> 
>   That should work *if* you have static libraries available.
> 
> > During linking phase, there are a bunch of problems; 1. libperl.a is not
> > found (that has been fixed by downloading Perl 5.8.8 and building it
> > locally); 2. many undefined functions, mainly in libkrb5.a
> 
>   Exactly.  Your OS has not supplied static libraries.  I suggest
> removing the modules you don't need, as that may help.  i.e. If you
> don't need kerberos, just "rm -rf src/modules/rlm_krb5".
> 
> > Is this a way to go? Has anyone successfully built freeradius 2.0.5 with
> > static linkage?
> 
>   A number of times.  Usually with various amounts of fighting the OS.
> 
>   I have no idea why vendors don't supply static libraries.  It's not
> like disk space is expensive these days.
> 
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

One big benefit of dynamic libraries is the ability to update a single
library and not need to recompile all the dependent software again. Also,
for completely valid reasons static libraries that use similar software
sub-components (zlib for example) will cause the statically linked application
to segfault if the version differs. Using the dynamic libraries also allows
the system to share common libraries amongst all running programs and make
more efficient use of machine resources. In the worst cases, a static executable
can cause a machine to swap/page where a dynamic version has no problems with
the same resources. I think for a combination of these and other reasons, many
vendors prefer dynamic libraries. Good luck with your static build, as Alan
states it may take some trial-and-error to get it to work. Our approach here
has been to localize all of the dependent dynamic libraries within the
software application directory. This simplifies the build/update process
by compartmentalizing the software from the normal system libraries and
makes it less susceptible to failure following an OS update.

My two cents,
Ken