- CLN-list - ginac.de

How to cite cln
by Wilson Castro 28 Jul '07

28 Jul '07

Hello cln-developers and cln-listmoderator, I want to know how it is the correct form to cite cln. 1. first in a paper? 2. in a GNU-software for Linux that uses the library? best regards -- Ms. C. Wilson Castro Rojas Foundations of Informatics Group, Department of Informatics, University of Kaiserslautern, Germany, PO Box: 3049, Building: 34/423, Phone: ++49 631 205 2155, Fax: ++49 631 205 2156,

5 33

[bug] CLN - pi example program does not report correct accuracy
by xt knight 28 Jul '07

28 Jul '07

Sorry, I posted this to ginac-list before I realized there was also a cln-list. I hope it gets to the right people involved. This is a simple bug and it's reproducible on every machine. Using the pi example in libcln (./examples), type this: pi 5 3.1415927 is not 5 digits. pi 1 3.1416 is not 1 digit. https://bugs.launchpad.net/debian/+source/cln/+bug/128851 This bug reporter also mentions that it rounds the last number and that's not documented anywhere. Thank you for your time, xtknight

1 0

bug in CLN RPM packaging system
by Markus Grabner 20 Jun '07

20 Jun '07

Hi! There is a small bug in the spec-file included in the CLN package "http://www.ginac.de/CLN/cln-1.1.13.tar.bz2". The package is compressed by "bzip2" and has extension ".bz2", but the spec-file refers to a "gzip"-compressed file with extension ".gz", so the command rpmbuild -ta cln-1.1.13.tar.bz2 fails. A workaround could be to uncompress the file and re-compress it with gzip, but this is somewhat inconvenient, and the issue is easily fixed by replacing ".gz" by ".bz2" in the spec-file. Kind regards, Markus -- Markus Grabner - Computer Graphics and Vision Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria Phone: +43/316/873-5041, Fax: +43/316/873-5050 WWW: http://www.icg.tugraz.at/Members/grabner

2 1

Multiple definition errors when natively compiling CLN 1.1.13 with GCC 3.4 for ARM target
by Simon Pickering 28 Feb '07

28 Feb '07

Hello, I'm attempting to compile CLN 1.1.13 using GCC 3.4 (inside scratchbox using qemu which allows GCC to be a native ARM compiler). I am compiling for the Nokia N800. I'm compiling with the following configure command: ./configure --with-gmp --prefix=/usr and with the following env vars: CPPFLAGS="-DNO_ASM" CXXFLAGS="-O2 -fno-exceptions -finline-limit=1000 -mfpu=vfp -mfloat-abi=softfp" I get the following error (trimmed as the preceeding command is very long): /bin/sh ../libtool --mode=link g++ -o libcln.la -rpath /usr/lib -version-info 4:2:0 -lgmp -objectlist libcln.objectlist g++ -shared -nostdlib /scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/lib/crti.o <snip> .libs/cl_asm_.o /usr/lib/libgmp.so -L/scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4 -L/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4 -L/scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/lib -lstdc++ -lm -lc -lgcc_s /scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4/crtendS.o /scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/lib/crtn.o -Wl,-soname -Wl,libcln.so.4 -o .libs/libcln.so.4.0.2 .libs/cl_I_ring.o: In function `cln::zerop(cln::cl_I const&)':cl_I_ring.cc:(.text._ZN3cln5zeropERKNS_4cl_IE[cln::zerop(cln::cl_I const&)]+0x0): multiple definition of `cln::zerop(cln::cl_I const&)' .libs/cl_I_zerop.o:cl_I_zerop.cc:(.text+0x0): first defined here .libs/cl_RA_ring.o: In function `cln::zerop(cln::cl_RA const&)':cl_RA_ring.cc:(.text._ZN3cln5zeropERKNS_5cl_RAE[cln::zerop(cln::cl_RA const&)]+0x0): multiple definition of `cln::zerop(cln::cl_RA const&)' .libs/cl_RA_zerop.o:cl_RA_zerop.cc:(.text+0x0): first defined here .libs/cl_R_signum.o: In function `cln::signum(cln::cl_I const&)':cl_R_signum.cc:(.text._ZN3cln6signumERKNS_4cl_IE[cln::signum(cln::cl_I const&)]+0x0): multiple definition of `cln::signum(cln::cl_I const&)' .libs/cl_I_signum.o:cl_I_signum.cc:(.text+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [libcln.la] Error 1 make[2]: Leaving directory `/home/simon/build/qcalculate/cln-1.1.13.orig/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/simon/build/qcalculate/cln-1.1.13.orig' make: *** [build] Error 2 I did a search of the mailing list archives and could only find this mentioned for MinGW. There was no solution as far as I could tell, but some talk of --param *inline* options that might make a difference. The installation instructions say the following: "If you use g++ on OSF/1 or Tru64 using gcc-2.95.x, you should specify `--disable-shared' because of linker problems with duplicate symbols in shared libraries.", which sounds like my problem, though obviously on a different platform & compiler version. I have tried altering -finline-limit (removing it, and changing the value to 10000), but to no avail, I still have the problem. I am trying to compile Qalculate, and even if I compile CLN to be a static library, I get linking errors due to the multiple functions when compiling libqalculate. Is there any way around this problem? Any other -finline*/--param options I could try, etc., or any other ideas? Many thanks, Simon P.S. I'm not subscribed to the list, but can do so if needed.

3 3

Re: cln cvs, cl_low_div.cc and mulu32_64
by Richard B. Kreckel 21 Dec '06

21 Dec '06

Hi! Thank you, Sven, for sending a patch. I'm talking this to the mailing list. (Since I'll start traveling in a couple of hours and come back next year.) There seems to be some confusion about the CLN version you're having. You say that you're using CLN 1.1.13. But your patch looks more like it is for CLN-1.2 from CVS HEAD, not for the CLN-1.1 branch. I've only had a quick glance at your patch. What is __arch64__ and why is __sparc64__ not defined? Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/> Sven Verdoolaege wrote: >On Thu, Dec 21, 2006 at 12:50:21AM +0100, Sven Verdoolaege wrote: > > >>I was trying to compile cln 1.1.13 on a sparc and I ran into some problems, >>so I thought I'd try the cvs version. >>I'm using gmp 4.2.1 (64 bits) and gcc 4.1.1 >> >>After fixing a couple of problems (see below), I'm stuck with this one: >> >>/bin/sh ../libtool --mode=compile g++ -m64 -mptr64 -I/home/verdoolaege/solaris-5.9-gcc-4.1.1/include/ -I../include -I../include -I./base -c ./base/low/cl_low_div.cc >> g++ -m64 -mptr64 -I/home/verdoolaege/solaris-5.9-gcc-4.1.1/include/ -I../include -I../include -I./base -c ./base/low/cl_low_div.cc -fPIC -DPIC -o .libs/cl_low_div.o >>./base/low/cl_low_div.cc: In function 'uint64 cln::divu_6464_6464_(uint64, uint64)': >>./base/low/cl_low_div.cc:262: error: 'mulu32_64' was not declared in this scope >> >>It seems you introduced this in your patch from Wed Mar 22 21:45:15 2006 +0000. >>mulu32_64 doesn't appear to be defined anywhere, neither in the current >>version nor in the version of that date: >> >> > >I'm assuming this should be mulu32_w. > >I now finally got cln compiled with the patch below, but now >the exam test segfaults: > >Program received signal SIGSEGV, Segmentation fault. >0xffffffff7edae178 in cln::cl_inc_pointer_refcount (pointer=0x0) > at ../include/cln/object.h:205 >205 pointer->refcount++; >(gdb) bt >#0 0xffffffff7edae178 in cln::cl_inc_pointer_refcount (pointer=0x0) > at ../include/cln/object.h:205 >#1 0xffffffff7edced28 in cln::cl_gcobject::inc_pointer_refcount ( > this=0xffffffff7f052e58) at ../include/cln/object.h:317 >#2 0xffffffff7edd716c in cln::cl_gcobject::_as_cl_private_thing ( > this=0xffffffff7f052e58) at ../include/cln/object.h:501 >#3 0xffffffff7ede06b4 in cln::as_cl_private_thing (x=@0xffffffff7f052e58) > at ../include/cln/object.h:506 >#4 0xffffffff7ee1d6ec in cl_DF (this=0xffffffff7f053400, > x=@0xffffffff7f052e58) at ../include/cln/dfloat_class.h:61 >#5 0xffffffff7ed10924 in cln::cl_I_to_DF (x=@0xffffffff7fffda88) > at float/dfloat/elem/cl_DF_from_I.cc:34 >#6 0xffffffff7ed10db8 in cln::cl_RA_to_DF (x=@0xffffffff7fffda88) > at float/dfloat/elem/cl_DF_from_RA.cc:36 >#7 0xffffffff7ed8f538 in __static_initialization_and_destruction_0 ( > __initialize_p=1, __priority=65535) > at real/format-output/cl_fmt_scaleexp.cc:50 >#8 0xffffffff7ed8f8f0 in global constructors keyed to _ZN3cln21format_scale_exponentERKNS_4cl_FE () at real/format-output/cl_fmt_scaleexp.cc:117 >#9 0xffffffff7ed9d9c0 in __do_global_ctors_aux () > at /solapplic/gcc-4.1.1/lib/gcc/sparc-sun-solaris2.9/4.1.1/../../../../include/c++/4.1.1/iostream:76 >#10 0xffffffff7ec7feb4 in _init () > from /home/verdoolaege/solaris-5.9-gcc-4.1.1/lib//libcln.so.5 >#11 0xffffffff7f612398 in call_init () from /lib/sparcv9/ld.so.1 >#12 0xffffffff7f611844 in setup () from /lib/sparcv9/ld.so.1 >#13 0xffffffff7f620a8c in _setup () from /lib/sparcv9/ld.so.1 >#14 0xffffffff7f605480 in _alias_start () from /lib/sparcv9/ld.so.1 >#15 0xffffffff7f605480 in _alias_start () from /lib/sparcv9/ld.so.1 >Previous frame identical to this frame (corrupt stack?) > >skimo > >diff --git a/include/cln/types.h b/include/cln/types.h >index 067411e..d46aaee 100644 >--- a/include/cln/types.h >+++ b/include/cln/types.h >@@ -48,7 +48,7 @@ > #undef HAVE_LONGLONG > #endif > #endif >- #if defined(HAVE_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || defined(__sparc64__) || defined(__x86_64__)) >+ #if defined(HAVE_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || defined(__sparc64__) || defined(__x86_64__) || defined(__arch64__)) > // 64 bit registers in hardware > #define HAVE_FAST_LONGLONG > #endif >diff --git a/src/base/cl_low.h b/src/base/cl_low.h >index 46485b9..226a448 100644 >--- a/src/base/cl_low.h >+++ b/src/base/cl_low.h >@@ -439,7 +439,7 @@ inline uint32 mulu32_unchecked (uint32 a > __asm__ __volatile__ ( \ > "wr %%g0,%%g0,%%y\n\t" \ > "udiv %2,%3,%0\n\t" \ >- "umul %0,%3,%1" \ >+ "umul %0,%3,%1\n\t" \ > "sub %2,%1,%1" \ > : "=&r" (__q), "=&r" (__r) \ > : "r" (__x), "r" (__y)); \ >@@ -528,7 +528,7 @@ inline uint32 mulu32_unchecked (uint32 a > __asm__ __volatile__ ( \ > "wr %%g0,%%g0,%%y\n\t" \ > "udiv %2,%3,%0\n\t" \ >- "umul %0,%3,%1" \ >+ "umul %0,%3,%1\n\t" \ > "sub %2,%1,%1" \ > : "=&r" (__q), "=&r" (__r) \ > : "r" (__x), "r" (__y)); \ >@@ -578,7 +578,7 @@ inline uint32 mulu32_unchecked (uint32 a > __asm__ __volatile__ ( \ > "wr %%g0,%%g0,%%y\n\t" \ > "udiv %2,%3,%0\n\t" \ >- "umul %0,%3,%1" \ >+ "umul %0,%3,%1\n\t" \ > "sub %2,%1,%1" \ > : "=&r" (__q), "=&r" (__r) \ > : "r" (__x), "r" (__y)); \ >@@ -690,7 +690,7 @@ inline uint32 mulu32_unchecked (uint32 a > __asm__ __volatile__ ( \ > "wr %2,%%g0,%%y\n\t" \ > "udiv %3,%4,%0\n\t" \ >- "umul %0,%4,%1" \ >+ "umul %0,%4,%1\n\t" \ > "sub %3,%1,%1" \ > : "=&r" (__q), "=&r" (__r) \ > : "r" (__xhi), "r" (__xlo), "r" (__y)); \ >@@ -791,7 +791,7 @@ inline uint32 mulu32_unchecked (uint32 a > __asm__ __volatile__ ( \ > "wr %2,%%g0,%%y\n\t" \ > "udiv %3,%4,%0\n\t" \ >- "umul %0,%4,%1" \ >+ "umul %0,%4,%1\n\t" \ > "sub %3,%1,%1" \ > : "=&r" (__q), "=&r" (__r) \ > : "r" (__xhi), "r" (__xlo), "r" (__y)); \ >diff --git a/src/base/digitseq/cl_asm_sparc64_.cc b/src/base/digitseq/cl_asm_sparc64_.cc >index e4acced..7936327 100644 >--- a/src/base/digitseq/cl_asm_sparc64_.cc >+++ b/src/base/digitseq/cl_asm_sparc64_.cc >@@ -40,6 +40,8 @@ > #define ret jmp %i7+8 // return from subroutine > #define retl jmp %o7+8 // return from leaf subroutine (no save/restore) > >+ .register %g2,#scratch >+ > .seg "text" > > .global C(mulu16_),C(mulu32_),C(mulu32_unchecked),C(mulu64_) >diff --git a/src/base/digitseq/cl_asm_sparc_.cc b/src/base/digitseq/cl_asm_sparc_.cc >index aac70ae..965ac0c 100644 >--- a/src/base/digitseq/cl_asm_sparc_.cc >+++ b/src/base/digitseq/cl_asm_sparc_.cc >@@ -39,6 +39,8 @@ > #define ret jmp %i7+8 // return from subroutine > #define retl jmp %o7+8 // return from leaf subroutine (no save/restore) > >+ .register %g2,#scratch >+ > .seg "text" > > .global C(mulu16_),C(mulu32_),C(mulu32_unchecked) >diff --git a/src/base/low/cl_low_div.cc b/src/base/low/cl_low_div.cc >index f631a51..64e8c36 100644 >--- a/src/base/low/cl_low_div.cc >+++ b/src/base/low/cl_low_div.cc >@@ -259,9 +259,9 @@ uint64 divu_6464_6464_(uint64 x, uint64 > } > // q = floor(x1/(y1+1)) > // x-q*y bilden (eine 32-mal-64-Bit-Multiplikation ohne Überlauf): >- x -= highlow64_0(mulu32_64(q,high32(y))); // q * high32(y) * beta >+ x -= highlow64_0(mulu32_w(q,high32(y))); // q * high32(y) * beta > // gefahrlos, da q*high32(y) <= q*y/beta <= x/beta < beta >- x -= mulu32_64(q,low32(y)); // q * low32(y) >+ x -= mulu32_w(q,low32(y)); // q * low32(y) > // gefahrlos, da q*high32(y)*beta + q*low32(y) = q*y <= x > // Noch höchstens 2 mal y abziehen: > if (x >= y) >diff --git a/src/polynomial/elem/cl_UP_GF2.h b/src/polynomial/elem/cl_UP_GF2.h >index fa2c5b1..f3c9936 100644 >--- a/src/polynomial/elem/cl_UP_GF2.h >+++ b/src/polynomial/elem/cl_UP_GF2.h >@@ -95,7 +95,7 @@ static const _cl_UP gf2_uminus (cl_heap_ > return x; > } > >-#if !(defined(__sparc__) || defined(__sparc64__)) >+#if (intDsize==64) > // Multiplication of polynomials over GF(2) can unfortunately not profit > // from hardware multiply instructions. Use a table instead. > // This is a 2^8 x 2^4 table. Maybe a 2^6 x 2^6 table would be better? > >

2 1

GCC 4.3 (experimental) -O2 dislikes intparam.h
by Ralf Wildenhues 20 Dec '06

20 Dec '06

When compiled with optimization -O2 and higher, the SVN trunk version of GCC miscompiles CLN's autoconf/intparam.c file. I cannot reproduce this with GCC-4.1.0 (no intermediate versions tested). The consequence of this is that the build fails very early due to #error's in the generated intparam.h file. I have reduced the difference to compiling the program below on GNU/Linux x86: $ gcc-4.3 -W -Wall -o foo foo.i $ ./foo /* Integers of type int have 32 bits. */ #define int_bitsize 32 $ gcc-4.3 -O2 -W -Wall -o foo foo.i $ ./foo #error "Integers of type int have no binary representation!!" Now, I was about to report a compiler bug ... except that I think the compiler is right here: integer overflow produces undefined behavior, so I think intparam.c should be fixed instead. With unsigned 'x', things are computed correctly. I guess you could just always use the respective unsigned variant for computing the bitsize of a type. (Using 'volatile int' helps with this GCC version, but I don't think that is guaranteed by the standard.) Next, please note that intparam.c uses exit but does not provide for a prototype. I recommend returning from main instead. Furthermore, please note that the CLN headers cause many "might break strict aliasing" warnings, and a few "will break strict aliasing" warnings. The latter are (at least) here: src/complex/ring/cl_C_ring.cc:131 src/rational/ring/cl_RA_ring.cc:129 src/real/ring/cl_R_ring.cc:133 Hope that helps. Cheers, Ralf /* foo.i */ extern int printf (__const char *__restrict __format, ...); static int int_bitsize; int main(void) { int x = 1; int bits = 0; while(1) { if (x==0) break; x = x+x; bits++; if (bits==1000) { bits = -1; break; } } int_bitsize = bits; if (int_bitsize >= 0) { printf("/* Integers of t%spe %s have %ld bits. */\n","y","int",(long)int_bitsize); if (!("int"[0] == 'u')) { printf("#define "); printf("int"); printf("_bitsize %ld\n",(long)int_bitsize); } printf("\n"); } else { printf("#error \"Integers of t%spe %s have no binary representation!!\"\n","y","int"); } return 0; }

2 5

thread-safety for CLN
by Kort Travis 22 Nov '06

22 Nov '06

[ P.S.: If this email is inappropriate for the general list, please let me know... ] I am presently working on a port of code-libraries which make extensive use of CLN to multi-threaded code (e.g. using OpenMP or explicit "by hand" threading), for use on multi-core and SMP systems. CLN release 1.1.13 is not re-entrant, and as far as I can tell from preliminary evaluation (and a large number of tests which produce major heap corruption), this is primarily because of the non-atomic reference counting (and possibly other mechanisms that I have not yet located). This means that I have the choice of either (a) switching to another, comparable class library (which as you know, probably doesn't exist) or (b) assisting in developing a thread-safe version of CLN. With this latter in mind, is anyone else working on this? If there is already a specification for this transition, please let me know how I can interface with the development work. Please note that this modification is something that I need urgently, and so I can potentially offer quite a bit of work to this project. Thanks! -- Kort Travis Department of Physics, RLM 5.208 University of Texas at Austin Austin, TX 78712 email: kat(a)physics.utexas.edu

3 2

cln compile error
by steve ayrgon 01 Nov '06

01 Nov '06

gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/java/jre --enable-mpfr --disable-libmudflap --disable-werror --enable-checking=release i386-pc-solaris2.11 --with-gnu-ld --with-gnu-as --with-ld=/usr/bin/ld --with-as=/usr/bin/as Thread model: posix gcc version 4.0.3 (GNU_Solaris 4.0.3-1nexenta6) # uname -a SunOS ... 5.11 NexentaOS_20061012 i86pc i386 i86pc Solari cln-1.1.13# make cd src && make all make[1]: Entering directory `/export/home/stieltje/Numerics/cln-1.1.13/src' make SUBDIR=base make[2]: Entering directory `/export/home/stieltje/Numerics/cln-1.1.13/src' /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_N_err_d0.cc mkdir .libs g++ -O -I../include -I../include -I./base -c ./base/cl_N_err_d0.cc -fPIC -DPIC -o .libs/cl_N_err_d0.o g++ -O -I../include -I../include -I./base -c ./base/cl_N_err_d0.cc -o cl_N_err_d0.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_abort.cc g++ -O -I../include -I../include -I./base -c ./base/cl_abort.cc -fPIC -DPIC -o .libs/cl_abort.o g++ -O -I../include -I../include -I./base -c ./base/cl_abort.cc -o cl_abort.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_alloca.cc g++ -O -I../include -I../include -I./base -c ./base/cl_alloca.cc -fPIC -DPIC -o .libs/cl_alloca.o g++ -O -I../include -I../include -I./base -c ./base/cl_alloca.cc -o cl_alloca.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_as_err.cc g++ -O -I../include -I../include -I./base -c ./base/cl_as_err.cc -fPIC -DPIC -o .libs/cl_as_err.o g++ -O -I../include -I../include -I./base -c ./base/cl_as_err.cc -o cl_as_err.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_condition.cc g++ -O -I../include -I../include -I./base -c ./base/cl_condition.cc -fPIC -DPIC -o .libs/cl_condition.o g++ -O -I../include -I../include -I./base -c ./base/cl_condition.cc -o cl_condition.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_debug.cc g++ -O -I../include -I../include -I./base -c ./base/cl_debug.cc -fPIC -DPIC -o .libs/cl_debug.o g++ -O -I../include -I../include -I./base -c ./base/cl_debug.cc -o cl_debug.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_debugout.cc g++ -O -I../include -I../include -I./base -c ./base/cl_debugout.cc -fPIC -DPIC -o .libs/cl_debugout.o g++ -O -I../include -I../include -I./base -c ./base/cl_debugout.cc -o cl_debugout.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_free.cc g++ -O -I../include -I../include -I./base -c ./base/cl_free.cc -fPIC -DPIC -o .libs/cl_free.o g++ -O -I../include -I../include -I./base -c ./base/cl_free.cc -o cl_free.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_immclasses.cc g++ -O -I../include -I../include -I./base -c ./base/cl_immclasses.cc -fPIC -DPIC -o .libs/cl_immclasses.o g++ -O -I../include -I../include -I./base -c ./base/cl_immclasses.cc -o cl_immclasses.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_malloc.cc g++ -O -I../include -I../include -I./base -c ./base/cl_malloc.cc -fPIC -DPIC -o .libs/cl_malloc.o g++ -O -I../include -I../include -I./base -c ./base/cl_malloc.cc -o cl_malloc.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_notreached.cc g++ -O -I../include -I../include -I./base -c ./base/cl_notreached.cc -fPIC -DPIC -o .libs/cl_notreached.o g++ -O -I../include -I../include -I./base -c ./base/cl_notreached.cc -o cl_notreached.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/cl_version.cc g++ -O -I../include -I../include -I./base -c ./base/cl_version.cc -fPIC -DPIC -o .libs/cl_version.o g++ -O -I../include -I../include -I./base -c ./base/cl_version.cc -o cl_version.o >/dev/null 2>&1 make SUBDIR=base/digit make[3]: Entering directory `/export/home/stieltje/Numerics/cln-1.1.13/src' /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/digit/cl_2D_div.cc g++ -O -I../include -I../include -I./base -c ./base/digit/cl_2D_div.cc -fPIC -DPIC -o .libs/cl_2D_div.o g++ -O -I../include -I../include -I./base -c ./base/digit/cl_2D_div.cc -o cl_2D_div.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -c ./base/digit/cl_2D_exptpos.cc g++ -O -I../include -I../include -I./base -c ./base/digit/cl_2D_exptpos.cc -fPIC -DPIC -o .libs/cl_2D_exptpos.o g++ -O -I../include -I../include -I./base -c ./base/digit/cl_2D_exptpos.cc -o cl_2D_exptpos.o >/dev/null 2>&1 make[3]: Leaving directory `/export/home/stieltje/Numerics/cln-1.1.13/src' make SUBDIR=base/digitseq make[3]: Entering directory `/export/home/stieltje/Numerics/cln-1.1.13/src' /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include -I./base -I./base/digit -I./base/random -Ibase -c ./base/digitseq/cl_2DS_div.cc g++ -O -I../include -I../include -I./base -I./base/digit -I./base/random -Ibase -c ./base/digitseq/cl_2DS_div.cc -fPIC -DPIC -o .libs/cl_2DS_div.o ../base/digitseq/cl_DS.h:50: error: expected identifier before numeric constant ../base/digitseq/cl_DS.h:50: error: expected unqualified-id before numeric constant ../base/digitseq/cl_DS.h:2652: error: expected identifier before numeric constant./base/digitseq/cl_DS.h:2652: error: expected ',' or '...' before numeric constant ../base/digitseq/cl_DS.h:2670: error: expected identifier before numeric constant./base/digitseq/cl_DS.h:2670: error: expected ',' or '...' before numeric constant make[3]: *** [cl_2DS_div.lo] Error 1 make[3]: Leaving directory `/export/home/stieltje/Numerics/cln-1.1.13/src' make[2]: *** [base/digitseq.target] Error 2 make[2]: Leaving directory `/export/home/stieltje/Numerics/cln-1.1.13/src' make[1]: *** [base.target] Error 2 make[1]: Leaving directory `/export/home/stieltje/Numerics/cln-1.1.13/src' make: *** [all] Error 2 _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

3 3

(no subject)
by steve ayrgon 25 Oct '06

25 Oct '06

sayrgon(a)hotmail.com _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

integer conversion functions weirdness
by varg＠theor.jinr.ru 19 Oct '06

19 Oct '06

Hello! Functions for conversion from cl_I into built-in integer types are a little bit weird: if conversion fails, CLN just aborts the program. This weirdness is documented in the manual: \begin{quote} `int cl_I_to_int (const cl_I& x)' `unsigned int cl_I_to_uint (const cl_I& x)' `long cl_I_to_long (const cl_I& x)' `unsigned long cl_I_to_ulong (const cl_I& x)' Returns `x' as element of the C type CTYPE. If `x' is not representable in the range of CTYPE, a runtime error occurs. \end{quote} So my question is: how do I check if the variable of cl_I type can be converted to int (or any other built-in integer type[s])? Best regards, Alexei. -- All science is either physics or stamp collecting.

3 4