Greetings, and thanks for your reply!
Steve Langasek <email@example.com> 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
And most importantly therefore:
camm@escher:~/gclcvs-2.7.0/unixport$ nm saved_pre_gcl |grep remq
Can this be due to some gcc configuration, or other toolchain
> 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
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> firstname.lastname@example.org http://www.debian.org/
Camm Maguire email@example.com
"The earth is but one country, and mankind its citizens." -- Baha'u'llah