From: Dr. W. F. <we...@su...> - 2006-05-23 14:12:58
|
Just to say it, the binary "foo" crashes in IA64 done during `make check' or `make check-exec-image'. The last successfull read is the read of the rheader in spvw_memfile.d:1518 with the size of 16, the next read with 128MB fails in unixaux.d:352. With this extrem large read, the mmaps of executable are broken and the runtime linker is fooled by this. Is there an approach to do the clisp object stuff hardware independent, that means that the layout of mappings of the architecture can be changed on the fly without breaking clisp? Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr |
From: Dr. W. F. <we...@su...> - 2006-05-23 14:26:23
|
On Tue, May 23, 2006 at 04:09:23PM +0200, Dr. Werner Fink wrote: > Just to say it, the binary "foo" crashes in IA64 done during > `make check' or `make check-exec-image'. > The last successfull read is the read of the rheader in > spvw_memfile.d:1518 with the size of 16, the next read with > 128MB fails in unixaux.d:352. With this extrem large read, > the mmaps of executable are broken and the runtime linker is > fooled by this. OK, with an unlimited stack size I get the message ./foo: initialization file `/usr/src/packages/BUILD/clisp-2.38/ia64-suse-linux/foo' was not created by this version of CLISP runtime which is not that what I want ;) > > Is there an approach to do the clisp object stuff hardware > independent, that means that the layout of mappings of the > architecture can be changed on the fly without breaking clisp? This question still remains. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr |