On Thu, Sep 15, 2005 at 08:56:07AM -0400, Camm Maguire wrote:
> Greetings, and thanks for your reply!
> 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
The output of the same command on my system:
$ for i in *.o; do if nm $i | grep __remq; then echo File: $i ; fi; done
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$
Likewise:
$ nm ../unixport/saved_pre_gcl |grep remq
U __remq@@GLIBC_2.0
U __remqu@@GLIBC_2.0
$
> Can this be due to some gcc configuration, or other toolchain
> mismatch?
I'm sure it could be due to any of a number of changes in the build
environment, but I'm not really keen to speculate which change is
responsible. If you can give me a list of build-dependency/toolchain
packages whose reported versions differ between the build log on goedel and
the chroot on escher, I can see if I can pin the blame on one of them.
--
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/
Attachment:
signature.asc
Description: Digital signature