Re: gclcvs_2.7.0-50

[Camm Maguire <camm@enhanced.com>]

Greetings, and thanks for your reply!

Steve Langasek <vorlon@debian.org> writes:

> On Wed, Sep 14, 2005 at 10:19:49AM -0400, Camm Maguire wrote:
> > Please requeue this package, as I cannot reproduce the autobuild
> > failure in dchroot on escher.  If this still fails, I suspect a
> > subarch specific gcc optimization on the autobuild machine (goedel).
> 
> Nothing has changed in the toolchain, though; is there really any reason to
> think that rebuilding will give a different result than the first pass gave?
> 
> I can reproduce the failure on my alpha with an up-to-date sid.  My alpha is
> the same class as escher, not goedel.
> 
> $ nm -u gcl-tk/tkl.o |grep __remq
>                  U __remq
> $ nm -D /lib/libc.so.6.1 |grep __remq
> 00000000000e0f20 T __remq
> 00000000000e10f0 T __remqu
> $

As far as I can see, this results from compiling the integer mod
operator '%' on alpha.  GCL collects all symbols with their addresses
from the set of conventionally compiled .c files in its 'raw' image
and builds a relocation table for use by
bfd_get_relocated_section_contents.  A module to be loaded therefore
must only reference symbols which are already compiled into the raw
image.  And __remq is present in several .o files in the o/
subdirectory.  As would be expected, tkl.o can be loaded without
failure at least in the gcl I built on escher.  (The loaded modules
are not shared objects and do not proceed via a dlopen mechanism,
primarily to enable the user to dump the image with the loaded modules
into a single executable via unexec.  Lush does this as well.)

In the case that one needs a symbol not present in the .o files, one
makes use of o/plttest.c, where explicit reference to the C functions
producing these symbols can be made.  

What I suspected is that somehow the autobuild machine, and perhaps
yours, is omitting __remq from any compiled .o object in the .o
directory.  Here is the list which contains __remq on escher:

camm@escher:~/gclcvs-2.7.0/o$ for i in *.o ; do if nm $i | grep __remq ; then echo File: $i ; fi ; done
File: alloc.o
                 U __remq
File: earith.o
                 U __remq
                 U __remqu
File: gbc.o
                 U __remqu
File: hash.o
                 U __remq
File: package.o
                 U __remq
File: print.o
                 U __remq
File: symbol.o
                 U __remqu
File: unixsave.o


And most importantly therefore:

camm@escher:~/gclcvs-2.7.0/unixport$ nm saved_pre_gcl |grep remq
                 U __remq@@GLIBC_2.0
                 U __remqu@@GLIBC_2.0
camm@escher:~/gclcvs-2.7.0/unixport$ 


Can this be due to some gcc configuration, or other toolchain
mismatch?

Thanks again,


> 
> I don't know how tkl.o is supposed to be loaded, since it's not a shared
> library and does not include ELF dependency information; but if it's
> supposed to be built in such a way that it has no undefined references to
> glibc symbols, you'll presumably need to use different compile flags.
> 
> Also in the list of undefined symbols is:
>                  U _setjmp
> 
> Cheers,
> -- 
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> vorlon@debian.org                                   http://www.debian.org/

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah