For the following discussion, we will assume that you have installed
the CLN source in $CLN_DIR
and built it in $CLN_TARGETDIR
.
For example, for me it's CLN_DIR="$HOME/cln"
and
CLN_TARGETDIR="$HOME/cln/linuxelf"
. You might define these as
environment variables, or directly substitute the appropriate values.
Until you have installed CLN in a public place, the following options are needed:
When you compile CLN application code, add the flags
-I$CLN_DIR/include -I$CLN_TARGETDIR/include
to the C++ compiler's command line (make
variable CFLAGS or CXXFLAGS).
When you link CLN application code to form an executable, add the flags
$CLN_TARGETDIR/src/libcln.a
to the C/C++ compiler's command line (make
variable LIBS).
If you did a make install
, the include files are installed in a
public directory (normally /usr/local/include
), hence you don't
need special flags for compiling. The library has been installed to a
public directory as well (normally /usr/local/lib
), hence when
linking a CLN application it is sufficient to give the flag -lcln
.
Here is a summary of the include files and their contents.
<cl_object.h>
<cl_number.h>
<cl_real.h>
<cl_float.h>
<cl_sfloat.h>
<cl_ffloat.h>
<cl_dfloat.h>
<cl_lfloat.h>
<cl_rational.h>
<cl_integer.h>
<cl_complex.h>
<cl_random.h>
<cl_malloc.h>
cl_malloc_hook
, cl_free_hook
.
<cl_abort.h>
cl_abort
.
<cl_io.h>
<cl_input.h>
<cl_output.h>
<cl_condition.h>
<cl_string.h>
<cl_symbol.h>
<cl_proplist.h>
<cl_ring.h>
<cl_numtheory.h>
<cl_modinteger.h>
<cl_V.h>
<cl_GV.h>
<cl_GV_integer.h>
<cl_GV_rational.h>
<cl_GV_real.h>
<cl_GV_complex.h>
<cl_GV_modinteger.h>
<cl_SV.h>
<cl_SV_integer.h>
<cl_SV_rational.h>
<cl_SV_real.h>
<cl_SV_complex.h>
<cl_SV_ringelt.h>
<cl_univpoly.h>
<cl_univpoly_integer.h>
<cl_univpoly_rational.h>
<cl_univpoly_real.h>
<cl_univpoly_complex.h>
<cl_univpoly_modint.h>
<cl_timing.h>
<cln.h>
(This section still needs to be written.)
When debugging a CLN application with GNU gdb
, two facilities are
available from the library:
cl_abort()
is
called. Its default implementation is to perform an exit(1)
, so
you won't have a core dump. But for debugging, it is best to set a
breakpoint at this function:
(gdb) break cl_abortWhen this breakpoint is hit, look at the stack's backtrace:
(gdb) where
print
command doesn't know about
CLN's types and therefore prints mostly useless hexadecimal addresses.
CLN offers a function cl_print
, callable from the debugger,
for printing number objects. In order to get this function, you have
to define the macro `CL_DEBUG' and then include all the header files
for which you want cl_print
debugging support. For example:
#define CL_DEBUG #include <cl_string.h>Now, if you have in your program a variable
cl_string s
, and
inspect it under gdb
, the output may look like this:
(gdb) print s $7 = {<cl_gcpointer> = { = {pointer = 0x8055b60, heappointer = 0x8055b60, word = 134568800}}, } (gdb) call cl_print(s) (cl_string) "" $8 = 134568800Note that the output of
cl_print
goes to the program's error output,
not to gdb's standard output.
Note, however, that the above facility does not work with all CLN types,
only with number objects and similar. Therefore CLN offers a member function
debug_print()
on all CLN types. The same macro `CL_DEBUG'
is needed for this member function to be implemented. Under gdb
,
you call it like this:
(gdb) print s $7 = {<cl_gcpointer> = { = {pointer = 0x8055b60, heappointer = 0x8055b60, word = 134568800}}, } (gdb) call s.debug_print() (cl_string) "" (gdb) define cprint >call ($1).debug_print() >end (gdb) cprint s (cl_string) ""Unfortunately, this feature does not seem to work under all circumstances.
Go to the first, previous, next, last section, table of contents.