On Thu, 8 Feb 2001 maxa@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@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@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 <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

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 2001 maxa@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 <ftp://ftpthep.physik.uni-mainz.de/pub/kreckel/>. 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 <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

On Mon, 12 Feb 2001 maxa@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 <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>