doc/advanced.html

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