From: Samuel Y. <sl...@il...> - 2008-11-12 12:54:00
|
OS: Solaris 10 Sparc Clisp version: 2.47 (also tried 2.45) Configure options used: --with-gnu-ld GCC version: 4.21 using gmake Build seems to get pretty far after many attempts and a learning curve. The CLISP logo is displayed. A long list of "Loading file .lisp.." are next. The last one before the error is clos-genfun4.lisp. I then get a handle_faulterror2 SIGSEGV cannot be cured fault address.... [Interpreted.mem] Segmentation Fault. I can provide more details if needed. Please help, I have been fighting this all week. I have installed libsigsegv-2.5(worked better than 2.6) binutils-2.17 libiconv-1.12 among other things I have tried. I am relatively new to this so bear with me. |
From: Sam S. <sd...@gn...> - 2008-11-12 14:42:19
|
Samuel Yost wrote: > OS: Solaris 10 Sparc is this a 64-bit machine? > Clisp version: 2.47 (also tried 2.45) > Configure options used: --with-gnu-ld > GCC version: 4.21 > using gmake > > Build seems to get pretty far after many attempts and a learning curve. > > The CLISP logo is displayed. A long list of "Loading file .lisp.." are next. > The last one before the error is clos-genfun4.lisp. > > I then get a handle_faulterror2 > SIGSEGV cannot be cured > fault address.... > [Interpreted.mem] Segmentation Fault. next time please copy and paste the whole error messages. > I can provide more details if needed. Please help, I have been fighting this > all week. > > I have installed > libsigsegv-2.5(worked better than 2.6) please report problems in libsigsegv 2.6 to Bruno. > binutils-2.17 > libiconv-1.12 > among other things I have tried. please take a look at the clisp/unix/PLATFORMS file. it has a section on "porting to new platforms" which is useful for this kinds of problems. please start with ./configure --with-libsigsegv-prefix=... --with-debug ---disable-mmap --cbc build-g thanks |
From: Samuel Y. <sl...@il...> - 2008-11-12 16:05:07
|
> > please start with > ./configure --with-libsigsegv-prefix=... --with-debug ---disable-mmap --cbc build-g > > thanks > > Tried the configure script with your options and it did not recognize the last three: --with-debug ---disable-mmap --cbc build-g. I am running it now with the libsigsegv option. |
From: Sam S. <sd...@gn...> - 2008-11-12 16:16:45
|
Samuel Yost wrote: >> please start with >> ./configure --with-libsigsegv-prefix=... --with-debug ---disable-mmap --cbc > build-g > > Tried the configure script with your options and it did not recognize the last > three: --with-debug ---disable-mmap --cbc build-g. I am running it now with > the libsigsegv option. what does "did not recognize" mean? please copy and paste your commands as well as the error messages. |
From: Samuel Y. <sl...@il...> - 2008-11-12 16:28:58
|
Sam Steingold <sds <at> gnu.org> writes: > > Samuel Yost wrote: > >> please start with > >> ./configure --with-libsigsegv-prefix=... --with-debug ---disable-mmap -- cbc > > build-g > > > > Tried the configure script with your options and it did not recognize the last > > three: --with-debug ---disable-mmap --cbc build-g. I am running it now with > > the libsigsegv option. > > what does "did not recognize" mean? > please copy and paste your commands as well as the error messages. > > My mistake. Running it now with your options. Sorry. |
From: Samuel Y. <sl...@il...> - 2008-11-12 16:52:58
|
Sam Steingold <sds <at> gnu.org> writes: > > please start with > ./configure --with-libsigsegv-prefix=... --with-debug ---disable-mmap --cbc build-g > > thanks > Here is what I ran: atlantis% ./configure --with-gnu-ld --with-libsigsegv-prefix=/usr/local --with-debug --disable-mmap --cbc build-g configure returned the following error: . ln -s ../src/spvw_calendar.c spvw_calendar.c make: Fatal error: Don't know how to make target `gllib/stdint.h' |
From: Sam S. <sd...@gn...> - 2008-11-12 17:07:49
|
Samuel Yost wrote: > > Here is what I ran: > atlantis% ./configure --with-gnu-ld --with-libsigsegv-prefix=/usr/local > --with-debug --disable-mmap --cbc build-g > > > configure returned the following error: > . > > ln -s ../src/spvw_calendar.c spvw_calendar.c > make: Fatal error: Don't know how to make target `gllib/stdint.h' this is weird: such an early error should have already appeared in your original build attempt. do you have build-g/gllib? try $ cd build-g $ rm -rf gllib $ make gllib or $ sh config.status gllib/Makefile depfiles |
From: Samuel Y. <sl...@il...> - 2008-11-12 19:11:25
|
I got the configure to work correctly using all of your options you suggested. I am still new at all of this so please bear with me. Now I get a different error at least ( I assume because it is using make instead of gmake). ---------------------- ;; Loading file /clisp/clisp-2.47/src/cmacros.lisp ... ;; Loaded file /clisp/clisp-2.47/src/cmacros.lisp ;; Loading file /clisp/clisp-2.47/src/compiler.lisp ... ;; Loaded file /clisp/clisp-2.47/src/compiler.lisp ;; Loading file /clisp/clisp-2.47/src/defs2.lisp ... *** - Compiler bug!! Occurred in VENV-SEARCH at #(FLAG #<UNKNOWN> #(ARG #<UNKNOWN> SUBCH #<UNKNOWN> #(CH #<UNKNOWN> #(STREAM #<UNKNOWN> #(VECTOR #<UNKNOWN> NIL))))). Bye. *** Error code 1 make: Fatal error: Command failed for target `interpreted.mem' atlantis% -------------------------------- If I then run gmake I get the following: ;; Loading file /clisp/clisp-2.45/src/clos-dependent.lisp ... ;; Loaded file /clisp/clisp-2.45/src/clos-dependent.lisp ;; Loading file /clisp/clisp-2.45/src/clos-genfun4.lisp ... *** - handle_fault error2 ! address = 0x81060e2c not in [0x664dd798,0x666f4000) ! SIGSEGV cannot be cured. Fault address = 0x81060e2c. Permanently allocated: 86752 bytes. Currently in use: 3607096 bytes. Free space: 687470 bytes. gmake: *** [interpreted.mem] Segmentation Fault |
From: Sam S. <sd...@gn...> - 2008-11-12 20:16:08
|
Samuel Yost wrote: > > Now I get a different error at least ( I assume because it is using make > instead of gmake). make version should not be able to affect the executable. if it does, I think it would be a good idea to investigate the differences by, e.g., comparing the output of "configure --cbc". > ---------------------- > ;; Loading file /clisp/clisp-2.47/src/cmacros.lisp ... > ;; Loaded file /clisp/clisp-2.47/src/cmacros.lisp > ;; Loading file /clisp/clisp-2.47/src/compiler.lisp ... > ;; Loaded file /clisp/clisp-2.47/src/compiler.lisp > ;; Loading file /clisp/clisp-2.47/src/defs2.lisp ... > *** - Compiler bug!! Occurred in VENV-SEARCH at #(FLAG #<UNKNOWN> #(ARG > #<UNKNOWN> SUBCH #<UNKNOWN> #(CH #<UNKNOWN> #(STREAM #<UNKNOWN> #(VECTOR > #<UNKNOWN> NIL))))). > Bye. > *** Error code 1 > make: Fatal error: Command failed for target `interpreted.mem' > atlantis% > > -------------------------------- > If I then run gmake I get the following: > > > ;; Loading file /clisp/clisp-2.45/src/clos-dependent.lisp ... > ;; Loaded file /clisp/clisp-2.45/src/clos-dependent.lisp > ;; Loading file /clisp/clisp-2.45/src/clos-genfun4.lisp ... > *** - handle_fault error2 ! address = 0x81060e2c not in > [0x664dd798,0x666f4000) > ! > SIGSEGV cannot be cured. Fault address = 0x81060e2c. > Permanently allocated: 86752 bytes. > Currently in use: 3607096 bytes. > Free space: 687470 bytes. > gmake: *** [interpreted.mem] Segmentation Fault first of all, you are building two different clisp versions (2.47 and 2.45). how about you just use the latest (2.47)? second, you are not building the debug version. please do configure --with-debug --cbc build-g |
From: Samuel Y. <sl...@il...> - 2008-11-13 20:56:13
|
I found a suggestion online to run mkheaders in the /usr/local/lib/gcc/sparc../3.../install-tools directory. Well that fixed the error "Don't know how to make target `gllib/stdint.h' and the siginfo errors. Now all I am left with is: unix.d:181: error: conflicting types for `signal' /usr/include/iso/signal_iso.h:48: error: previous declaration of `signal' make: Fatal error: Command failed for target `spvw.o' |
From: Samuel Y. <sl...@il...> - 2008-11-12 14:55:57
|
Yes it is 64 bit. I am re-running the gmake now and will post the exact messages when it is done. Takes quite a while to finish. I have looked in the file you mentioned but it did not help. Thanks, Sam Yost |
From: Raymond T. <toy...@gm...> - 2008-11-13 00:40:06
|
Samuel Yost wrote: > OS: Solaris 10 Sparc > Clisp version: 2.47 (also tried 2.45) > Configure options used: --with-gnu-ld > GCC version: 4.21 > using gmake > > As Sam may recall, I have successfully built clisp 2.47 on Solaris 10. The most important thing was to use the right version of gcc. I tried quite a few, but I had the best luck with gcc 3.3.x. I know gcc 4.3.x fails. The version that comes with Solaris 10 also fails. I get segfaults when running interpreted.mem, too, I think. I'd try gcc 3.3.x if possible. Ray |
From: Sam S. <sd...@gn...> - 2008-11-13 14:53:24
|
Raymond Toy wrote: > Samuel Yost wrote: >> OS: Solaris 10 Sparc >> Clisp version: 2.47 (also tried 2.45) >> Configure options used: --with-gnu-ld >> GCC version: 4.21 >> using gmake >> >> > As Sam may recall, I have successfully built clisp 2.47 on Solaris 10. > The most important thing was to use the right version of gcc. I tried > quite a few, but I had the best luck with gcc 3.3.x. I know gcc 4.3.x > fails. The version that comes with Solaris 10 also fails. I get > segfaults when running interpreted.mem, too, I think. > > I'd try gcc 3.3.x if possible. Is this only for solaris 10 or solaris 8 also? do you think you can file a gcc bug report based on your testing? (I think this would require you to compare assembly produces by gcc 3 & 4) |
From: Raymond T. <ray...@er...> - 2008-11-13 16:25:30
|
Sam Steingold wrote: > Raymond Toy wrote: >> Samuel Yost wrote: >>> OS: Solaris 10 Sparc >>> Clisp version: 2.47 (also tried 2.45) >>> Configure options used: --with-gnu-ld >>> GCC version: 4.21 >>> using gmake >>> >>> >> As Sam may recall, I have successfully built clisp 2.47 on Solaris 10. >> The most important thing was to use the right version of gcc. I tried >> quite a few, but I had the best luck with gcc 3.3.x. I know gcc 4.3.x >> fails. The version that comes with Solaris 10 also fails. I get >> segfaults when running interpreted.mem, too, I think. >> >> I'd try gcc 3.3.x if possible. > > Is this only for solaris 10 or solaris 8 also? Yes, both solaris 10 and 8. Unfortunately, I deleted all the pretest directories so I can't look to see what I actually tried out. But solaris 8, I have gcc 3.2.2, 3.3.[123], 3.4.3, 4.2.2, and 4.3.2. On solaris 10, I have 3.3.3 and 4.3.2 (and 3.4.3 that comes with Solaris). I'm pretty sure only 3.3.x worked. > do you think you can file a gcc bug report based on your testing? > (I think this would require you to compare assembly produces by gcc 3 & 4) I suppose I could, but I wouldn't know where to begin, and I not really keen on comparing the assembly output for every single file. Ray |
From: Sam S. <sd...@gn...> - 2008-11-13 16:47:07
|
Raymond Toy wrote: > Sam Steingold wrote: > >> do you think you can file a gcc bug report based on your testing? >> (I think this would require you to compare assembly produces by gcc 3 & 4) > > I suppose I could, but I wouldn't know where to begin, and I not really > keen on comparing the assembly output for every single file. is this a flat "no" or do I have a chance? the issue is pretty important: we gotta make gcc4 compile CLISP on all platforms! what needs to be done is the following: 1. figure out which D file is miscompiled by gcc4: configure 2 build dirs, working build-gcc3 and segfaulting build-gcc4. then copy the .o files from the gcc4 directory into the gcc3 directory one by one and figure out which .o file causes the build to fail. 2. once you have the single file, you can then compare the assembly - or give it to Bruno who eats it for breakfast. Sam. |
From: Raymond T. <ray...@er...> - 2008-11-13 17:00:36
|
Sam Steingold wrote: > Raymond Toy wrote: >> Sam Steingold wrote: >> >>> do you think you can file a gcc bug report based on your testing? >>> (I think this would require you to compare assembly produces by gcc 3 >>> & 4) >> >> I suppose I could, but I wouldn't know where to begin, and I not really >> keen on comparing the assembly output for every single file. > > is this a flat "no" or do I have a chance? > the issue is pretty important: we gotta make gcc4 compile CLISP on all > platforms! It's not a flat no, but I won't make any promises. > > what needs to be done is the following: > 1. figure out which D file is miscompiled by gcc4: > configure 2 build dirs, working build-gcc3 and segfaulting build-gcc4. > then copy the .o files from the gcc4 directory into the gcc3 directory > one by one and figure out which .o file causes the build to fail. Hmm. There's only 67 .o files. That's not so bad. As long as only one file is needed to cause a segfault. What do you really want? Do you want me to copy over one file and try it. If it's ok, do I restore the original and try again? Or can I just copy over the next? Any particular order? I'm not going to promise anything though, but I will try to help. I also don't follow gcc releases very much because I can't use prebuilt binaries and have to build them myself. That sometimes takes days (because the build itself takes many, many hours, some versions don't actually configure/build correctly, and I invariably make mistakes.) Ray |
From: Sam S. <sd...@gn...> - 2008-11-13 17:21:23
|
Raymond Toy wrote: > It's not a flat no, but I won't make any promises. >> what needs to be done is the following: >> 1. figure out which D file is miscompiled by gcc4: >> configure 2 build dirs, working build-gcc3 and segfaulting build-gcc4. >> then copy the .o files from the gcc4 directory into the gcc3 directory >> one by one and figure out which .o file causes the build to fail. > > Hmm. There's only 67 .o files. That's not so bad. As long as only one > file is needed to cause a segfault. let us hope so. > What do you really want? Do you want me to copy over one file and try > it. If it's ok, do I restore the original and try again? Or can I just > copy over the next? Any particular order? I suggest that you start with stream io symbol package charstrg array sequence lisparit hashtabl eval control spvw > I'm not going to promise anything though, but I will try to help. thanks! |
From: Raymond T. <ray...@er...> - 2008-11-13 17:29:45
|
Sam Steingold wrote: > Raymond Toy wrote: >> It's not a flat no, but I won't make any promises. >>> what needs to be done is the following: >>> 1. figure out which D file is miscompiled by gcc4: >>> configure 2 build dirs, working build-gcc3 and segfaulting build-gcc4. >>> then copy the .o files from the gcc4 directory into the gcc3 directory >>> one by one and figure out which .o file causes the build to fail. >> >> Hmm. There's only 67 .o files. That's not so bad. As long as only one >> file is needed to cause a segfault. > > let us hope so. > >> What do you really want? Do you want me to copy over one file and try >> it. If it's ok, do I restore the original and try again? Or can I just >> copy over the next? Any particular order? > > I suggest that you start with Should the originals be restored if there's no segfault? Ray |
From: Sam S. <sd...@gn...> - 2008-11-13 17:37:24
|
Raymond Toy wrote: > Sam Steingold wrote: >> Raymond Toy wrote: >>> It's not a flat no, but I won't make any promises. >>>> what needs to be done is the following: >>>> 1. figure out which D file is miscompiled by gcc4: >>>> configure 2 build dirs, working build-gcc3 and segfaulting build-gcc4. >>>> then copy the .o files from the gcc4 directory into the gcc3 directory >>>> one by one and figure out which .o file causes the build to fail. >>> Hmm. There's only 67 .o files. That's not so bad. As long as only one >>> file is needed to cause a segfault. >> let us hope so. >> >>> What do you really want? Do you want me to copy over one file and try >>> it. If it's ok, do I restore the original and try again? Or can I just >>> copy over the next? Any particular order? >> I suggest that you start with > > Should the originals be restored if there's no segfault? yes, I think so. |
From: Hughes, B. [UK] <William.Hughes@CGI.COM> - 2008-11-13 17:59:23
|
Sam Steingold wrote: > Raymond Toy wrote: >> Sam Steingold wrote: >>> Raymond Toy wrote: >>>> It's not a flat no, but I won't make any promises. >>>>> what needs to be done is the following: >>>>> 1. figure out which D file is miscompiled by gcc4: >>>>> configure 2 build dirs, working build-gcc3 and segfaulting >>>>> build-gcc4. then copy the .o files from the gcc4 directory into >>>>> the gcc3 >>>>> directory one by one and figure out which .o file causes the >>>>> build to fail. >>>> Hmm. There's only 67 .o files. That's not so bad. As long as >>>> only one file is needed to cause a segfault. >>> let us hope so. >>> >>>> What do you really want? Do you want me to copy over one file and >>>> try it. If it's ok, do I restore the original and try again? Or >>>> can I just copy over the next? Any particular order? I suggest >>>> that you start with >> >> Should the originals be restored if there's no segfault? > > yes, I think so. If there's any chance that some of the .o files are the same it may be worth running a diff between the two sets. It might cut down the candidates a little. Bill -- *** Confidentiality Notice *** Proprietary/Confidential Information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply email. A CGI Group Inc. Company Registered address: Broadlands House, Primett Road, Stevenage, Hertfordshire, SG1 3EE, United Kingdom. Registered in England and Wales - Number 2843595 |
From: Raymond T. <ray...@er...> - 2008-11-13 18:58:44
|
Sam Steingold wrote: >> What do you really want? Do you want me to copy over one file and try >> it. If it's ok, do I restore the original and try again? Or can I just >> copy over the next? Any particular order? > > I suggest that you start with > stream > io That was quick. stream.o was ok. But io.o causes an error: ;; Loading file /apps/public/src/lisp/clisp-2.47/build-sol10-gcc-3.3.3/compiler.fas ... *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"/apps/public/src/lisp/clisp-2.47/build-sol10-gcc-3.3.3/compiler.fas" @4>: illegal syntax of closure code vector after #77Y Bye. make: *** [halfcompiled.mem] Error 1 I was expecting a segfault, but maybe this is a good starting point. What do you want me to do now? Ray |
From: Raymond T. <ray...@er...> - 2008-11-13 20:05:58
|
Sam Steingold wrote: > Raymond Toy wrote: >> That was quick. stream.o was ok. But io.o causes an error: >> >> ;; Loading file >> /apps/public/src/lisp/clisp-2.47/build-sol10-gcc-3.3.3/compiler.fas ... >> *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER >> #P"/apps/public/src/lisp/clisp-2.47/build-sol10-gcc-3.3.3/compiler.fas" >> @4>: illegal syntax of closure code vector after #77Y >> Bye. >> make: *** [halfcompiled.mem] Error 1 >> >> I was expecting a segfault, but maybe this is a good starting point. >> >> What do you want me to do now? > > first, make sure compiler.fas is really OK :-) How do I do that? > > second, do "make io.s" in the gcc3 and gcc4 directories and compare the > results. > the files will be huge, but the diffs might not be all that humongous. > if they are, I am afraid the sequence is: $ wc io.s ../build-sol10-gcc-3.3.3/io.s 154749 315555 2390170 io.s 53485 116942 1425733 ../build-sol10-gcc-3.3.3/io.s I'm sorry, but I think this is where I draw the line: the plain diff -u has 201788 lines. I can provide the files to anyone who wants to look, though. If he provides an updated io.s, I'm willing to run it. Or I can give access to a Solaris 8 box for anyone who wants to play with this (but it will take some time to get gcc 3 and gcc 4 on it.) Sorry, Ray > > 1. take the working io.s generated by gcc3. > 2. replace a function there from the io.s generated by gcc4. > 3. compile io.s into io.o and link lisp.run > 4. try make. > 5. if it works, repeat 1. > if it does not - you now have the function which is miscompiled. > this can be optimized by using a binary search. > > Bruno, please step in! > > Sam. |
From: Sam S. <sd...@gn...> - 2008-11-14 16:03:29
|
Raymond Toy wrote: > Sam Steingold wrote: >> Raymond Toy wrote: >>> That was quick. stream.o was ok. But io.o causes an error: >>> >>> ;; Loading file >>> /apps/public/src/lisp/clisp-2.47/build-sol10-gcc-3.3.3/compiler.fas ... >>> *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER >>> #P"/apps/public/src/lisp/clisp-2.47/build-sol10-gcc-3.3.3/compiler.fas" >>> @4>: illegal syntax of closure code vector after #77Y >>> Bye. >>> make: *** [halfcompiled.mem] Error 1 >>> >>> I was expecting a segfault, but maybe this is a good starting point. >>> >>> What do you want me to do now? >> first, make sure compiler.fas is really OK :-) > > How do I do that? > >> second, do "make io.s" in the gcc3 and gcc4 directories and compare the >> results. >> the files will be huge, but the diffs might not be all that humongous. >> if they are, I am afraid the sequence is: > > $ wc io.s ../build-sol10-gcc-3.3.3/io.s > 154749 315555 2390170 io.s > 53485 116942 1425733 ../build-sol10-gcc-3.3.3/io.s I wonder why the gcc3-generated file is so much smaller. are the options the same? (-O2 et al) does gcc4 work with "-O0"? thanks |
From: Raymond T. <ray...@er...> - 2008-11-14 17:26:19
|
Sam Steingold wrote: > Raymond Toy wrote: >> Sam Steingold wrote: >>> Raymond Toy wrote: >>>> That was quick. stream.o was ok. But io.o causes an error: >>>> >>>> ;; Loading file >>>> /apps/public/src/lisp/clisp-2.47/build-sol10-gcc-3.3.3/compiler.fas ... >>>> *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER >>>> #P"/apps/public/src/lisp/clisp-2.47/build-sol10-gcc-3.3.3/compiler.fas" >>>> @4>: illegal syntax of closure code vector after #77Y >>>> Bye. >>>> make: *** [halfcompiled.mem] Error 1 >>>> >>>> I was expecting a segfault, but maybe this is a good starting point. >>>> >>>> What do you want me to do now? >>> first, make sure compiler.fas is really OK :-) >> >> How do I do that? >> >>> second, do "make io.s" in the gcc3 and gcc4 directories and compare the >>> results. >>> the files will be huge, but the diffs might not be all that humongous. >>> if they are, I am afraid the sequence is: >> >> $ wc io.s ../build-sol10-gcc-3.3.3/io.s >> 154749 315555 2390170 io.s >> 53485 116942 1425733 ../build-sol10-gcc-3.3.3/io.s > > I wonder why the gcc3-generated file is so much smaller. The gcc 3.3.3 file has lots of debugging stabs lines. The 4.3.2 version doesn't. Both were compiled (via make) using: gcc -I/apps/public/solaris2.10/include -I/apps/gnu/solaris2.10/include -Igllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fno-schedule-insns -fno-gcse -falign-functions=4 -DUNIX_BINARY_DISTRIB -DUNICODE -DNO_GETTEXT -I. -S io.c I also tried this: diff -ibw -I "^.*.stab.*" -u <3.3.3> <4.3.2> Although there are some 200K lines in the diff, the diffs are a little easier to read. It's still pretty hard to figure out what really changed, but there are lots of changes in the generated code. It appears, roughly, that 4.3.2 tends to use the global %g registers much more often than 4.3.2. Maybe this is the problem? I did get lots of warnings about global register values (or something like that). Ray |
From: Sam S. <sd...@gn...> - 2008-11-14 17:14:06
|
Raymond Toy wrote: >> first, make sure compiler.fas is really OK :-) > How do I do that? does it terminate at line 4 where the error is reported? it not, it is OK for our purposes. |