From: Tobias C. R. <tc...@fr...> - 2009-07-05 11:52:50
|
"/src/tcr/contributing/sbcl-git/src/cold/shared.lisp" > #<"SB-COLD" package> SB-COLD> "obj/from-xc/" SB-COLD> ;;; Loading "/src/tcr/contributing/sbcl-git/src/cold/set-up-cold-packages.lisp" "/src/tcr/contributing/sbcl-git/src/cold/set-up-cold-packages.lisp" SB-COLD> ;;; Loading "/src/tcr/contributing/sbcl-git/src/cold/defun-load-or-cload-xcompiler.lisp" "/src/tcr/contributing/sbcl-git/src/cold/defun-load-or-cload-xcompiler.lisp" SB-COLD> Filesystem error with pathname #P"obj/from-host/src/code/cross-early.lisp-obj". Either 1) the file does not exist, or 2) we are not allow to access the file, or 3) the pathname points to a broken symbolic link. Broken at SI:BYTECODES.No restarts available. Broken at LOAD-OR-CLOAD-XCOMPILER. File: #P"/src/tcr/contributing/sbcl-git/src/cold/defun-load-or-cload-xcompiler.lisp" (Form #1) SB-COLD>> //testing for consistency of first and second GENESIS passes //header files match between first and second GENESIS -- good 8.98user 0.93system 0:13.22elapsed 74%CPU (0avgtext+0avgdata 0maxresident)k 352inputs+11248outputs (1major+258070minor)pagefaults 0swaps //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.29.54.rc1, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. fatal error encountered in SBCL pid 23448(tid 3085141680): can't load .core for different runtime, sorry Welcome to LDB, a low-level debugger for the Lisp runtime environment. |
From: Tobias C. R. <tc...@fr...> - 2009-07-05 12:07:46
|
"Tobias C. Rittweiler" <tc...@fr...> writes: > SB-COLD> Filesystem error with pathname #P"obj/from-host/src/code/cross-early.lisp-obj". > Either > 1) the file does not exist, or > 2) we are not allow to access the file, or > 3) the pathname points to a broken symbolic link. > Broken at SI:BYTECODES.No restarts available. For some reason the file is called cross-early.FAS not .LISP-OBJ. -T. |
From: Gabriel D. R. <gd...@in...> - 2009-07-05 14:25:01
|
On Sun, Jul 5, 2009 at 7:07 AM, Tobias C. Rittweiler<tc...@fr...> wrote: > "Tobias C. Rittweiler" <tc...@fr...> writes: > >> SB-COLD> Filesystem error with pathname #P"obj/from-host/src/code/cross-early.lisp-obj". >> Either >> 1) the file does not exist, or >> 2) we are not allow to access the file, or >> 3) the pathname points to a broken symbolic link. >> Broken at SI:BYTECODES.No restarts available. > > For some reason the file is called cross-early.FAS not .LISP-OBJ. I had a fix for this particular failure -- after Juanjo changed the way ECL handles pathname extension for compile-filename. You need to apply the following AND use a recent version of ECL (cvs from yesterday for example). Index: src/cold/shared.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/cold/shared.lisp,v retrieving revision 1.41 diff -p -r1.41 shared.lisp *** src/cold/shared.lisp 5 May 2009 20:02:12 -0000 1.41 --- src/cold/shared.lisp 5 Jul 2009 14:22:06 -0000 *************** *** 48,53 **** --- 48,54 ---- #+lispworks ".ufsl" ; as per Lieven Marchand sbcl-devel 2002-02-01 #+(and openmcl (not darwin)) ".pfsl" #+(and openmcl darwin) ".dfsl" + #+ecl ".fas" ;; On most xc hosts, any old extension works, so we use an ;; arbitrary one. ".lisp-obj")) I hope someone will commit it to SBCL. After that, you will hit another failure -- one with multiple slot problem. I hope someone here will shed a light about whether it is ECL bug or SBCL bug. -- Gaby |
From: Christophe R. <cs...@ca...> - 2009-07-05 14:53:10
|
"Tobias C. Rittweiler" <tc...@fr...> writes: > [snip] I'm not desperately surprised that building from ECL fails; as far as I know, it's never been supported. If you have a need to make it supported, then patches to that effect would be welcome, but it's not something that I plan to act on myself. Best, Christophe |
From: Gabriel D. R. <gd...@in...> - 2009-07-05 15:08:21
|
On Sun, Jul 5, 2009 at 9:53 AM, Christophe Rhodes<cs...@ca...> wrote: > "Tobias C. Rittweiler" <tc...@fr...> writes: > >> [snip] > > I'm not desperately surprised that building from ECL fails; as far as > I know, it's never been supported. Some of us would like that to happen. > If you have a need to make it > supported, then patches to that effect would be welcome, I sent a trivial patch for the very failure Tobias reported. It gets us a bit far in order to investigate other problem. Would you mind taking a look at it and possibly apply it? > but it's not > something that I plan to act on myself. That is understood. |
From: Nikodemus S. <nik...@ra...> - 2009-07-05 15:58:31
|
2009/7/5 Gabriel Dos Reis <gd...@in...>: > On Sun, Jul 5, 2009 at 9:53 AM, Christophe Rhodes<cs...@ca...> wrote: >> "Tobias C. Rittweiler" <tc...@fr...> writes: >> >>> [snip] >> >> I'm not desperately surprised that building from ECL fails; as far as >> I know, it's never been supported. > > Some of us would like that to happen. > >> If you have a need to make it >> supported, then patches to that effect would be welcome, > > I sent a trivial patch for the very failure Tobias reported. > It gets us a bit far in order to investigate other problem. > Would you mind taking a look at it and possibly apply it? I'm interested in ECL as a supported build host, but I don't think merging patches that each get one bit further in the build is the best way. I at least would much rather merge a singular "add ELC is a working host" patch or patch series. Of course, _sharing_ baby-step patches on the lists is perfectly sensible. I just don't think they necessarily belong in CVS before they actually accomplish their stated goal. Cheers, -- Nikodemus |
From: Gabriel D. R. <gd...@in...> - 2009-07-05 16:18:51
|
On Sun, Jul 5, 2009 at 10:58 AM, Nikodemus Siivola<nik...@ra...> wrote: > 2009/7/5 Gabriel Dos Reis <gd...@in...>: >> On Sun, Jul 5, 2009 at 9:53 AM, Christophe Rhodes<cs...@ca...> wrote: >>> "Tobias C. Rittweiler" <tc...@fr...> writes: >>> >>>> [snip] >>> >>> I'm not desperately surprised that building from ECL fails; as far as >>> I know, it's never been supported. >> >> Some of us would like that to happen. >> >>> If you have a need to make it >>> supported, then patches to that effect would be welcome, >> >> I sent a trivial patch for the very failure Tobias reported. >> It gets us a bit far in order to investigate other problem. >> Would you mind taking a look at it and possibly apply it? > > I'm interested in ECL as a supported build host, but I don't think > merging patches that each get one bit further in the build is the best > way. I at least would much rather merge a singular "add ELC is a > working host" patch or patch series. Sure, I understand that. One may think of my earlier patch as one of the patch series. Note that I had to convince ECL maintainers that the change was necessary in order to get SBCL working with ECL. Others -- as I've seen through private emails -- are interested as well. > > Of course, _sharing_ baby-step patches on the lists is perfectly > sensible. I just don't think they necessarily belong in CVS before > they actually accomplish their stated goal. > > Cheers, > > -- Nikodemus > |
From: Christophe R. <cs...@ca...> - 2009-07-05 16:41:32
|
Gabriel Dos Reis <gd...@in...> writes: > Note that I had to convince ECL maintainers that the change was > necessary in order to get SBCL working with ECL. Others -- as I've > seen through private emails -- are interested as well. OK, fair enough. (I'm slightly intrigued as to why, but I suppose I'm the last person to question people's motivation in this respect). Best, Christophe |
From: Gabriel D. R. <gd...@in...> - 2009-07-05 16:47:53
|
On Sun, Jul 5, 2009 at 11:41 AM, Christophe Rhodes<cs...@ca...> wrote: > Gabriel Dos Reis <gd...@in...> writes: > >> Note that I had to convince ECL maintainers that the change was >> necessary in order to get SBCL working with ECL. Others -- as I've >> seen through private emails -- are interested as well. > > OK, fair enough. (I'm slightly intrigued as to why, but I suppose I'm > the last person to question people's motivation in this respect). There many reasons (apparently each individual with his/her own reasons.) In my case, it is that CLISP is no longer a reliable to bootstrap SBCL. ECL, on the other hand has proven to be more portable. -- Gaby |
From: Christophe R. <cs...@ca...> - 2009-07-05 17:39:42
|
Gabriel Dos Reis <gd...@in...> writes: > On Sun, Jul 5, 2009 at 11:41 AM, Christophe Rhodes<cs...@ca...> wrote: >> Gabriel Dos Reis <gd...@in...> writes: >> >>> Note that I had to convince ECL maintainers that the change was >>> necessary in order to get SBCL working with ECL. Others -- as I've >>> seen through private emails -- are interested as well. >> >> OK, fair enough. (I'm slightly intrigued as to why, but I suppose I'm >> the last person to question people's motivation in this respect). > > There many reasons (apparently each individual with his/her own reasons.) > In my case, it is that CLISP is no longer a reliable to bootstrap SBCL. > ECL, on the other hand has proven to be more portable. Um, it should be. I did a signficant amount of work in April to make it reliable (see <http://www.advogato.org/person/crhodes/diary.html?start=129>) and I consider clisp build failures to be regressions. (I don't know whether ECL is more portable or not, but since cross-compiling SBCL is so easy I'm not sure I see why that's relevant). Best, Christophe |
From: Gabriel D. R. <gd...@in...> - 2009-07-05 18:09:15
|
On Sun, Jul 5, 2009 at 12:39 PM, Christophe Rhodes<cs...@ca...> wrote: > Gabriel Dos Reis <gd...@in...> writes: > >> On Sun, Jul 5, 2009 at 11:41 AM, Christophe Rhodes<cs...@ca...> wrote: >>> Gabriel Dos Reis <gd...@in...> writes: >>> >>>> Note that I had to convince ECL maintainers that the change was >>>> necessary in order to get SBCL working with ECL. Others -- as I've >>>> seen through private emails -- are interested as well. >>> >>> OK, fair enough. (I'm slightly intrigued as to why, but I suppose I'm >>> the last person to question people's motivation in this respect). >> >> There many reasons (apparently each individual with his/her own reasons.) >> In my case, it is that CLISP is no longer a reliable to bootstrap SBCL. >> ECL, on the other hand has proven to be more portable. > > Um, it should be. I did a signficant amount of work in April to make > it reliable (see > <http://www.advogato.org/person/crhodes/diary.html?start=129>) and I > consider clisp build failures to be regressions. (I don't know > whether ECL is more portable or not, but since cross-compiling SBCL is > so easy I'm not sure I see why that's relevant). sorry for being unclear: I was talking about building CLISP *itself*, not building SBCL with CLISP. -- Gaby |