From fell at shore.net Mon Feb 5 17:28:01 2001 From: fell at shore.net (richard noel fell) Date: Mon, 05 Feb 2001 11:28:01 -0500 Subject: not really a bug Message-ID: <3A7ED491.746EA1EE@shore.net> I am using redhat linux 7.0 and have installed CLN. I have downloaded the ginac rpm, but the installer fails to find the CLN libraries. Where should I put CLN so ginac can be installed? Thanks for your help, Dick Fell From cbauer at student.physik.uni-mainz.de Mon Feb 5 16:34:10 2001 From: cbauer at student.physik.uni-mainz.de (Christian Bauer) Date: Mon, 5 Feb 2001 16:34:10 +0100 Subject: not really a bug In-Reply-To: <3A7ED491.746EA1EE@shore.net>; from fell@shore.net on Mon, Feb 05, 2001 at 11:28:01AM -0500 References: <3A7ED491.746EA1EE@shore.net> Message-ID: <20010205163410.A14353@iphcip1.physik.uni-mainz.de> Hi! On Mon, Feb 05, 2001 at 11:28:01AM -0500, richard noel fell wrote: > I am using redhat linux 7.0 and have installed CLN. I have downloaded > the ginac rpm, but the installer fails to find the CLN libraries. Where > should I put CLN so ginac can be installed? If you didn't install CLN from the provided RPM package, you have to supply the "--nodeps" option to rpm when installing the GiNaC package. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ From kreckel at thep.physik.uni-mainz.de Thu Feb 8 13:28:28 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Thu, 8 Feb 2001 13:28:28 +0100 (CET) Subject: Yesterday it was late... Message-ID: ...which is why the announcement for version 0.7.1 didn't go out. It's to be found on the usual places. It is mainly a bug-fix release, but some of the stuff may represent a heavy improvement. In particular, all those folks who were having this or that particular algebraic problem since 0.7.0, please see if it's been solved. Luck -richy. PS: By the way, this is the second 7 February release... -- Richard Kreckel From maxa at frodo.jia.czn.cz Thu Feb 8 21:39:56 2001 From: maxa at frodo.jia.czn.cz (maxa at frodo.jia.czn.cz) Date: Thu, 8 Feb 101 12:26:14 -0800 (PST) Subject: Problem with CLN on Alpha In-Reply-To: from "Richard B. Kreckel" at Jan 30, 1 11:03:16 am Message-ID: <200102082026.MAA22404@mail.jia.czn.cz> > > On Mon, 29 Jan 101 maxa at frodo.jia.czn.cz wrote: > > Reading specs from /usr/local/lib/gcc-lib/alphapca56-unknown-linux-gnu/egcs-2.91.60/specs > > gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) > > Expect problems. Upgrade compiler. Use GCC-2.95.2. While at it, upgrade > binutils (i.e. ld), too. > > Luck > -richy. > -- > Richard Kreckel > > Hi all! I am trying to compile CLN library on an Alpha machine. Now I upgraded the compiler and binutils but I am still getting a lot of undefined symbols (see below). Can anybody help? Was anybody able to compile cln on an Alpha machi- ne? Thanks. Best regards, Ladislav Zejda zejdaz at mbox.vol.cz Problem: after running "make" I am getting: ... /bin/sh ../libtool --mode=link c++ -O3 -g -fno-exceptions -L/usr/local/gmp-3.1.1/lib/ exam.o exam_I.o exam_RA.o exam_SF.o exam_FF.o exam_DF.o exam_LF.o exam_I_gcd.o exam_I_sqrtp.o ../src/libcln.la -lm -o exam mkdir .libs c++ -O3 -g -fno-exceptions -L/usr/local/gmp-3.1.1/lib/ exam.o exam_I.o exam_RA.o exam_SF.o exam_FF.o exam_DF.o exam_LF.o exam_I_gcd.o exam_I_sqrtp.o ../src/.libs/libcln.so -lm -o .libs/exam -Wl,--rpath -Wl,/usr/local/cln-1.1/lib exam.o: In function `__static_initialization_and_destruction_0': cln-1.1/include/cln/io.h:91: undefined reference to `_GLOBAL_$I$cl_module__cl_prin_globals__firstglobalfun' cln-1.1/include/cln/io.h:91: undefined reference to `_GLOBAL_$I$cl_module__cl_prin_globals__firstglobalfun' exam.o: In function `__static_initialization_and_destruction_0': cln-1.1/include/cln/random.h:36: undefined reference to `_GLOBAL_$I$cl_module__cl_random_def__firstglobalfun' cln-1.1/include/cln/random.h:36: undefined reference to `_GLOBAL_$I$cl_module__cl_random_def__firstglobalfun' exam.o: In function `__static_initialization_and_destruction_0': cln-1.1/include/cln/dfloat_class.h:55: undefined reference to `_GLOBAL_$I$cl_module__cl_DF_globals__firstglobalfun' cln-1.1/include/cln/dfloat_class.h:55: undefined reference to `_GLOBAL_$I$cl_module__cl_DF_globals__firstglobalfun' exam.o: In function `__static_initialization_and_destruction_0': ... and so on My setup (now it should be up-to-date): cat /proc/version Linux version 2.2.11 (root at zelva.jia.czn.cz) (gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)) #46 Mon Aug 2 13:19:49 PDT 1999 cat /proc/cpuinfo cpu : Alpha cpu model : EV56 cpu variation : 0 cpu revision : 0 cpu serial number : Linux_is_Great! system type : EB164 system variation : SX164 system revision : 0 system serial number : MILO-0000 cycle frequency [Hz] : 533171648 timer frequency [Hz] : 1024.00 page size [bytes] : 8192 phys. address bits : 40 max. addr. space # : 127 BogoMIPS : 528.48 kernel unaligned acc : 7 (pc=fffffc0000449014,va=fffffc000029ef32) user unaligned acc : 2009927 (pc=2000000ec70,va=20000282764) platform string : N/A g++ -v Reading specs from /usr/local/gcc-2.95.2/lib/gcc-lib/alphapca56-unknown-linux-gnu/2.95.2/specs gcc version 2.95.2 19991024 (release) ld -v GNU ld version 2.10.91 (with BFD 2.10.1.0.4) From kreckel at thep.physik.uni-mainz.de Thu Feb 8 22:18:48 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Thu, 8 Feb 2001 22:18:48 +0100 (CET) Subject: Problem with CLN on Alpha In-Reply-To: <200102082026.MAA22404@mail.jia.czn.cz> Message-ID: On Thu, 8 Feb 101 maxa at frodo.jia.czn.cz wrote: > I am trying to compile CLN library on an Alpha machine. Now I upgraded the > compiler and binutils but I am still getting a lot of undefined symbols (see > below). Can anybody help? Was anybody able to compile cln on an Alpha machi- > ne? Yes, me. No problem at all. Actually I was extremely careful testing version 1.1 on any platform I could get my hands on before I released it. > Thanks. Best regards, > Ladislav Zejda > zejdaz at mbox.vol.cz > > Problem: > after running "make" I am getting: > > ... > > /bin/sh ../libtool --mode=link c++ -O3 -g -fno-exceptions -L/usr/local/gmp-3.1.1/lib/ exam.o exam_I.o exam_RA.o exam_SF.o exam_FF.o exam_DF.o exam_LF.o exam_I_gcd.o exam_I_sqrtp.o ../src/libcln.la -lm -o exam > mkdir .libs > c++ -O3 -g -fno-exceptions -L/usr/local/gmp-3.1.1/lib/ exam.o exam_I.o exam_RA.o exam_SF.o exam_FF.o exam_DF.o exam_LF.o exam_I_gcd.o exam_I_sqrtp.o ../src/.libs/libcln.so -lm -o .libs/exam -Wl,--rpath -Wl,/usr/local/cln-1.1/lib > exam.o: In function `__static_initialization_and_destruction_0': > cln-1.1/include/cln/io.h:91: undefined reference to `_GLOBAL_$I$cl_module__cl_prin_globals__firstglobalfun' > cln-1.1/include/cln/io.h:91: undefined reference to `_GLOBAL_$I$cl_module__cl_prin_globals__firstglobalfun' > exam.o: In function `__static_initialization_and_destruction_0': > cln-1.1/include/cln/random.h:36: undefined reference to `_GLOBAL_$I$cl_module__cl_random_def__firstglobalfun' > cln-1.1/include/cln/random.h:36: undefined reference to `_GLOBAL_$I$cl_module__cl_random_def__firstglobalfun' > exam.o: In function `__static_initialization_and_destruction_0': > cln-1.1/include/cln/dfloat_class.h:55: undefined reference to `_GLOBAL_$I$cl_module__cl_DF_globals__firstglobalfun' > cln-1.1/include/cln/dfloat_class.h:55: undefined reference to `_GLOBAL_$I$cl_module__cl_DF_globals__firstglobalfun' > exam.o: In function `__static_initialization_and_destruction_0': > > ... and so on > > My setup (now it should be up-to-date): > cat /proc/version > Linux version 2.2.11 (root at zelva.jia.czn.cz) (gcc version egcs-2.91.60 19981201 > (egcs-1.1.1 release)) #46 Mon Aug 2 13:19:49 PDT 1999 > > cat /proc/cpuinfo > cpu : Alpha > cpu model : EV56 > cpu variation : 0 > cpu revision : 0 > cpu serial number : Linux_is_Great! > system type : EB164 > system variation : SX164 > system revision : 0 > system serial number : MILO-0000 > cycle frequency [Hz] : 533171648 > timer frequency [Hz] : 1024.00 > page size [bytes] : 8192 > phys. address bits : 40 > max. addr. space # : 127 > BogoMIPS : 528.48 > kernel unaligned acc : 7 (pc=fffffc0000449014,va=fffffc000029ef32) > user unaligned acc : 2009927 (pc=2000000ec70,va=20000282764) > platform string : N/A FYI: Kernel doesn't matter for such things... > g++ -v > Reading specs from /usr/local/gcc-2.95.2/lib/gcc-lib/alphapca56-unknown-linux-gnu/2.95.2/specs > gcc version 2.95.2 19991024 (release) > > ld -v > GNU ld version 2.10.91 (with BFD 2.10.1.0.4) Hmm, this setup should work fine. Just one more question (check box): About *how* many undefined symbols did you get? [ ] about 10 [ ] about 100 [ ] about 1000 For me, the link line in your report works just fine. You obviously have some linker confusion. Don't you have a local Linux guru who might help you out with this stuff? You could also try a static library only. Regards -richy. -- Richard Kreckel From maxa at frodo.jia.czn.cz Sat Feb 10 02:35:20 2001 From: maxa at frodo.jia.czn.cz (maxa at frodo.jia.czn.cz) Date: Fri, 9 Feb 101 17:21:36 -0800 (PST) Subject: Problem with CLN on Alpha In-Reply-To: from "Richard B. Kreckel" at Feb 8, 1 10:18:48 pm Message-ID: <200102100121.RAA28682@mail.jia.czn.cz> > > On Thu, 8 Feb 101 maxa at frodo.jia.czn.cz wrote: > > I am trying to compile CLN library on an Alpha machine. Now I upgraded the > > compiler and binutils but I am still getting a lot of undefined symbols (see > > below). Can anybody help? Was anybody able to compile cln on an Alpha machi- > > ne? > > Yes, me. No problem at all. Actually I was extremely careful testing > version 1.1 on any platform I could get my hands on before I released it. Thanks for the reply. Very interesting indeed. Can we compare a little bit more? > About *how* many undefined symbols did you get? > [ ] about 10 > [X] about 100 > [ ] about 1000 Just exactly: grep -e "undefined" --count make.logfile 178 > For me, the link line in your report works just fine. You obviously have > some linker confusion. Don't you have a local Linux guru who might help > you out with this stuff? Unfortunately there is no Linux guru aroung, except me. Looking at the problem in more details, all undefined symbols comes from names like _GLOBAL_$I$cl_module__cl_*__firstglobalfun or _GLOBAL_$D$cl_module__cl_*__firstglobalfun . Looking at object files (which I am linking), none of them has those symbols defined, so I think my linker is right. Are those symbols defined? If yes, where they should be defined? Could the problem be related to the configure? There is one line which makes me wonder if it's right: checking whether the global constructors function need to be exported... yes > > You could also try a static library only. > I have already tried, but that's the same problem. > Regards > -richy. > -- > Richard Kreckel > > > Thanks for your help! Best regards, Ladislav Zejda zejdaz at mbox.vol.cz From kreckel at thep.physik.uni-mainz.de Mon Feb 12 17:20:58 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Mon, 12 Feb 2001 17:20:58 +0100 (CET) Subject: Problem with CLN on Alpha In-Reply-To: <200102100121.RAA28682@mail.jia.czn.cz> Message-ID: Hi Ladislav, First, your email address (the maxa@ -one) is screwed. Each time I reply the message bounces, yet you respond... On Fri, 9 Feb 101 maxa at frodo.jia.czn.cz wrote: > > > I am trying to compile CLN library on an Alpha machine. Now I upgraded the > > > compiler and binutils but I am still getting a lot of undefined symbols (see > > > below). Can anybody help? Was anybody able to compile cln on an Alpha machi- > > > ne? > > > > Yes, me. No problem at all. Actually I was extremely careful testing > > version 1.1 on any platform I could get my hands on before I released it. > > Thanks for the reply. Very interesting indeed. Can we compare a little bit > more? Sure. > > About *how* many undefined symbols did you get? > > [ ] about 10 > > [X] about 100 > > [ ] about 1000 > Just exactly: > grep -e "undefined" --count make.logfile > 178 Aha, it doesn't look like such a simple linker screw as I had expected first. > > For me, the link line in your report works just fine. You obviously have > > some linker confusion. Don't you have a local Linux guru who might help > > you out with this stuff? > > Unfortunately there is no Linux guru aroung, except me. Looking at the problem > in more details, all undefined symbols comes from names like > > _GLOBAL_$I$cl_module__cl_*__firstglobalfun > or > _GLOBAL_$D$cl_module__cl_*__firstglobalfun > > . Looking at object files (which I am linking), none of them has those symbols > defined, so I think my linker is right. Are those symbols defined? If yes, > where they should be defined? The global ctors and dtors are sitting right there where they belong to. I just tried compiling CLN-1.1 from scratch on a Debian potato Alpha box. Looking at all the object files I see them there: wino:/tmp/cln-1.1$ uname -a Linux wino 2.2.17 #1 Wed Sep 27 17:00:52 CEST 2000 alpha unknown wino:/tmp/cln-1.1$ ld -v GNU ld version 2.9.5 (with BFD 2.9.5.0.37) wino:/tmp/cln-1.1$ gcc -v Reading specs from /usr/lib/gcc-lib/alpha-linux/2.95.2/specs gcc version 2.95.2 20000220 (Debian GNU/Linux) wino:/tmp/cln-1.1/src$ for i in *.o; do nm $i |grep "T _GLOBAL_\$I\$cl_module__cl_" |grep "__firstglobalfun" >> /dev/null && echo "$i "; done cl_0_ring.o cl_C_ring.o cl_DF_globals.o cl_FF_globals.o cl_F_catalanconst_var.o cl_F_epsneg.o cl_F_epspos.o cl_F_eulerconst_var.o cl_F_exp1_var.o cl_F_leastneg.o cl_F_leastpos.o cl_F_ln10_var.o cl_F_ln2_var.o cl_F_mostneg.o cl_F_mostpos.o cl_F_pi_var.o cl_GV_I.o cl_GV_number.o cl_I_doublefactorial.o cl_I_factorial.o cl_I_ring.o cl_LF_globals.o cl_MI.o cl_RA_ring.o cl_R_ring.o cl_SV_number.o cl_SV_ringelt.o cl_UP.o cl_UP_named.o cl_UP_no_ring.o cl_UP_unnamed.o cl_fmt_floatstring.o cl_fmt_scaleexp.o cl_ieee.o cl_no_ring.o cl_prin_globals.o cl_random_def.o cl_st_null.o cl_symbol.o > Could the problem be related to the configure? There is one line which makes > me wonder if it's right: > > checking whether the global constructors function need to be exported... yes No, that is just fine. That macro checks whether to export the global ctor/dtor, as needed by the scope of EGCS >= 1.1.2. Another macro checks whether it is _GLOBAL_$D$cl_module__ (as on Alpha) or GLOBAL_.D.cl_module__ (as on Intel) or even something else. So I am still rather clueless what is happening. You were having optimization switched on so you didn't fall into that include/cln/modules.h trap. Really, I have no idea... > > You could also try a static library only. > > > I have already tried, but that's the same problem. For your convenience, I have uploaded the static library I just compiled to . You should be able to do some debugging with this. Please do tell us when you find out what was wrong. Regards -richy. -- Richard Kreckel From maxa at frodo.jia.czn.cz Tue Feb 13 02:09:21 2001 From: maxa at frodo.jia.czn.cz (maxa at frodo.jia.czn.cz) Date: Mon, 12 Feb 101 16:55:45 -0800 (PST) Subject: Problem with CLN on Alpha - solved In-Reply-To: from "Richard B. Kreckel" at Feb 12, 1 05:20:58 pm Message-ID: <200102130055.QAA28837@mail.jia.czn.cz> Hi Richy, > On Fri, 9 Feb 101 maxa at frodo.jia.czn.cz wrote: > > > > I am trying to compile CLN library on an Alpha machine. Now I upgraded the > > > > compiler and binutils but I am still getting a lot of undefined symbols (see > > > > below). Can anybody help? Was anybody able to compile cln on an Alpha machi- > > > > ne? > rather clueless what is happening. You were having optimization switched > on so you didn't fall into that include/cln/modules.h trap. Really, I > have no idea... > For your convenience, I have uploaded the static library I just compiled > to . You should be able > to do some debugging with this. Please do tell us when you find out what > was wrong. > > Regards > -richy. > -- > Richard Kreckel > > Thank you very much for the static library. I compared your and my library and I find some differences (for example: "nm cl_prin_globals.o"): correct: 00000000000001a0 T _GLOBAL_$D$cl_module__cl_prin_globals__firstglobalfun U _GLOBAL_$D$cl_module__cl_st_null__firstglobalfun 0000000000000160 T _GLOBAL_$I$cl_module__cl_prin_globals__firstglobalfun U _GLOBAL_$I$cl_module__cl_st_null__firstglobalfun wrong: 00000000000001a0 t _GLOBAL_$D$_3cln$default_print_flags U _GLOBAL_$D$cl_module__cl_prin_globals__firstglobalfun U _GLOBAL_$D$cl_module__cl_st_null__firstglobalfun 0000000000000160 t _GLOBAL_$I$_3cln$default_print_flags U _GLOBAL_$I$cl_module__cl_prin_globals__firstglobalfun U _GLOBAL_$I$cl_module__cl_st_null__firstglobalfun And since you mentioned the optimization, I tried different levels, and the solution is here! G++ miscompiles CLN if no optimization (-O0) is used and if too much optimization (-O3) is used. So, when I switched back to -O2 level, all is fine. Great! Thanks a lot! Cheers, Ladislav Zejda zejdaz at mbox.vol.cz PS: > First, your email address (the maxa@ -one) is screwed. Each time I reply > the message bounces, yet you respond... Actually my address maxa at frodo.jia.czn.cz is correct, but it's not usable for sending e-mail to me since it's the address of my home computer when it's con- nected to the Internet. And that's usually just a short time since it's very expensive for a physics student here. So, please always use the address of my incoming mailbox: zejdaz at mbox.vol.cz . My e-mail contains the line "Reply-To: zejdaz at mbox.vol.cz" so the reply should work well. From kreckel at thep.physik.uni-mainz.de Tue Feb 13 14:00:23 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Tue, 13 Feb 2001 14:00:23 +0100 (CET) Subject: Problem with CLN on Alpha - solved In-Reply-To: <200102130055.QAA28837@mail.jia.czn.cz> Message-ID: On Mon, 12 Feb 101 maxa at frodo.jia.czn.cz wrote: > Thank you very much for the static library. I compared your and my library > and I find some differences (for example: "nm cl_prin_globals.o"): > > correct: > 00000000000001a0 T _GLOBAL_$D$cl_module__cl_prin_globals__firstglobalfun > U _GLOBAL_$D$cl_module__cl_st_null__firstglobalfun > 0000000000000160 T _GLOBAL_$I$cl_module__cl_prin_globals__firstglobalfun > U _GLOBAL_$I$cl_module__cl_st_null__firstglobalfun > > wrong: > 00000000000001a0 t _GLOBAL_$D$_3cln$default_print_flags > U _GLOBAL_$D$cl_module__cl_prin_globals__firstglobalfun > U _GLOBAL_$D$cl_module__cl_st_null__firstglobalfun > 0000000000000160 t _GLOBAL_$I$_3cln$default_print_flags > U _GLOBAL_$I$cl_module__cl_prin_globals__firstglobalfun > U _GLOBAL_$I$cl_module__cl_st_null__firstglobalfun > > And since you mentioned the optimization, I tried different levels, and the > solution is here! G++ miscompiles CLN if no optimization (-O0) is used and if > too much optimization (-O3) is used. So, when I switched back to -O2 level, all > is fine. Great! Thank you very much for finding out what causes the problem. It is well known that the PROVIDE/REQUIRE macros defined in include/cln/modules.h cannot work with -O0. This is why the CLN configure script sets CXXFLAGS to -O (equivalent to -O1) if you haven't specified it. This is in contrast to other configure scripts which set it to -O2 -g. But -O2 doesn't help CLN much. The main differerence between -O1 and -O2 is the enhanced scheduling. But since an awful amount of code in CLN is of the if (((long)p & 3) == 0) *((int*)p)++ kind, scheduling cannot take much effect at such short basic block sizes. Inlining, in contrast, as switched on with -O1 helps a lot. I still have to find out what goes wrong with -O3. Regards -richy. -- Richard Kreckel From kreckel at thep.physik.uni-mainz.de Sat Feb 17 19:37:15 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Sat, 17 Feb 2001 19:37:15 +0100 (CET) Subject: Just another release Message-ID: This is to inform you that version 0.7.2 went out a couple of seconds ago. Q: Is it worth the upgrade from 0.7.1? A: Not unless you are doing some serious stuff with power series expansion. Q: What's going to happen next? A: A major cleanup regarding all things that do not compute is going on. This might also include a more convenient syntax for matrix operations and such things. Q: What do you guys in your spare time? A: Spare time? What's spare time? Q: Will this new version have effects on my sex life? A: Again, if you are doing serious stuff with power series, then it might very well have some effects. Hunting down bugs late at night is known to disturb your sanity. We just did that for you... luck -richy. From kreckel at thep.physik.uni-mainz.de Sat Feb 17 20:27:16 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Sat, 17 Feb 2001 20:27:16 +0100 (CET) Subject: Just another release In-Reply-To: Message-ID: > Q: What's going to happen next? > A: A major cleanup regarding all things that do not compute is going on. > This might also include a more convenient syntax for matrix operations > and such things. s/compute/commute/ Jeez -richy. From kreckel at thep.physik.uni-mainz.de Wed Feb 28 21:55:34 2001 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Wed, 28 Feb 2001 21:55:34 +0100 (CET) Subject: There's news... Message-ID: ...on . In short: 0.7.3 is out. Please do hammer on it! Luck -richy. -- Richard Kreckel