Problem with CLN on Alpha

[Richard B. 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 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 <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 at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>