<option>-o</option> option.
  </para>

  <para>
   The preprocessed file can be compiled normally, for example:
<programlisting>
cc -c prog1.c
</programlisting>
   The generated C source files include header files from the
   <productname>PostgreSQL</productname> installation, so if you installed
   <productname>PostgreSQL</productname> in a location that is not searched by
   default, you have to add an option such as
   <literal>-I/usr/local/pgsql/include</literal> to the compilation
   command line.
  </para>

  <para>
   To link an embedded SQL program, you need to include the
   <filename>libecpg</filename> library, like so:
<programlisting>
cc -o myprog prog1.o prog2.o ... -lecpg
</programlisting>
   Again, you might have to add an option like
   <literal>-L/usr/local/pgsql/lib</literal> to that command line.
  </para>

  <para>
   You can
   use <command>pg_config</command><indexterm><primary>pg_config</primary><secondary sortas="ecpg">with
   ecpg</secondary></indexterm>
   or <command>pkg-config</command><indexterm><primary>pkg-config</primary><secondary sortas="ecpg">with
   ecpg</secondary></indexterm> with package name <literal>libecpg</literal> to
   get the paths for your installation.
  </para>

  <para>
   If you manage the build process of a larger project using
   <application>make</application>, it might be convenient to include
   the following implicit rule to your makefiles:
<programlisting>
ECPG = ecpg

%.c: %.pgc
        $(ECPG) $&lt;
</programlisting>
  </para>

  <para>
   The complete syntax of the <command>ecpg</command> command is
   detailed in <xref linkend="app-ecpg"/>.
  </para>

  <para>
   The <application>ecpg</application> library is thread-safe by
   default.  However, you might need to use some threading
   command-line options to compile your client code.
  </para>
 </sect1>

 <sect1 id="ecpg-library">
  <title>Library Functions</title>

  <para>
   The <filename>libecpg</filename> library primarily contains
   <quote>hidden</quote> functions that are used to implement the
   functionality expressed by the embedded SQL commands.  But there
   are some functions that can usefully be called directly.  Note that
   this makes your code unportable.
  </para>

  <itemizedlist>
   <listitem>
    <para>
     <function>ECPGdebug(int <replaceable>on</replaceable>, FILE
     *<replaceable>stream</replaceable>)</function> turns on debug
     logging if called with the first argument non-zero. Debug logging
     is done on <replaceable>stream</replaceable>.  The log contains
     all <acronym>SQL</acronym> statements with all the input
     variables inserted, and the results from the
     <productname>PostgreSQL</productname> server. This can be very
     useful when searching for errors in your <acronym>SQL</acronym>
     statements.
    </para>
    <note>
    <para>
    On Windows, if the <application>ecpg</application> libraries and an application are
    compiled with different flags, this function call will crash the
    application because the internal representation of the
    <literal>FILE</literal> pointers differ.  Specifically,
    multithreaded/single-threaded, release/debug, and static/dynamic
    flags should be the same for the library and all applications using
    that library.
    </para>
    </note>
   </listitem>

   <listitem>
     <para>
       <function>ECPGget_PGconn(const char *<replaceable>connection_name</replaceable>)
       </function> returns the library database connection handle identified by the given name.
       If <replaceable>connection_name</replaceable> is set to <literal>NULL</literal>, the current
       connection handle is returned. If no connection handle can be identified, the function returns
       <literal>NULL</literal>. The returned connection handle can be used to call any other functions
       from <application>libpq</application>, if necessary.
     </para>
     <note>
     <para>
       It is a bad idea to manipulate database connection handles