1<HTML><head> 2<TITLE>Cyrus SASL Library -- Advanced Usage</TITLE> 3</head> 4<body> 5<h1>Cyrus SASL library, version 2.0</h1> 6<h2>Notes for Advanced Usage of libsasl</h2> 7 8<h3>Using Cyrus SASL as a static library</h3> 9As of v2.0.2-ALPHA, Cyrus SASL supports the option to compile all of the 10supported mechanisms and glue code into a single static library that may 11be linked into any application. In practice, this saves memory by avoiding 12the need to have a jump table for each process's reference into the shared 13library, and ensures that all the mechanisms are loaded when the application 14loads (thus reducing the overhead of loading the DSOs).<P> 15 16However, this is not a recommended procedure to use in general. It loses 17the flexibility of the DSOs that allow one to simply drop in a new mechanism 18that even currently-running applications will see for each new connection. 19That is, if you choose to use the static version of the library, not only 20will you need to recompile the library each time you add a mechanism (provided 21the mechanisms even support being compiled staticly), but you will need to 22recompile every application that uses Cyrus SASL as well.<P> 23 24However, if you are sure you wish to use a static version of Cyrus SASL, 25compile it by giving <tt>configure</tt> the <tt>--enable-static</tt> option. 26This will compile <b>both</b> a dynamic and a static version. Then, whenever 27an application links to libsasl, it will also need to explicitly pull in 28any dynamic libraries that may be needed by Cyrus SASL. Most notably, these 29might include the GSSAPI, Kerberos, and Database libraries. To avoid compiling 30the dynamic version, pass <tt>--disable-shared</tt>.<P> 31 32<hr> 33Back to the <A href=index.html>index</a> 34 35</body> 36