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