Hi, 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 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 Is this a way to go? Has anyone successfully built freeradius 2.0.5 with static linkage? Thanks! Abhay
abhay@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.
On Tue, Aug 05, 2008 at 04:40:05PM +0200, Alan DeKok wrote:
abhay@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
On Tue, 2008-08-05 at 16:40 +0200, Alan DeKok wrote:
I have no idea why vendors don't supply static libraries. It's not like disk space is expensive these days.
Many of them do supply static libraries, but they are part of a different package. At least on Red Hat-based systems, if you have a libblotto package, it only installs the dynamic libraries. If you want to link statically, then you need libblotto-devel. So you may just need some -devel packages. The problems with statically linking have already been pretty well covered here by someone else. --Greg
participants (4)
-
abhay＠clearcrypt.com -
Alan DeKok -
Greg Woods -
Kenneth Marshall