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/>