From: Gabriel D. R. <gd...@in...> - 2010-10-05 18:59:42
|
Hi, SBCL builds fails with Clozure CL as bootstrapping Lisp system. Apparently, it is picky about use of undefined functions. ? #P"/home/gdr/src/sbcl.cvs/src/cold/set-up-cold-packages.lisp" ? #P"/home/gdr/src/sbcl.cvs/src/cold/defun-load-or-cload-xcompiler.lisp" ? T ? T ? ;Compiler warnings for "src/code/backq.lisp" : ; In SB!INT:SIMPLE-READER-ERROR: Undefined function SB!INT:BUG ;Compiler warnings for "src/code/cross-misc.lisp" : ; In SB!KERNEL:%DPB: Undefined function SB-XC:BYTE ; In SB!KERNEL:%DPB: Undefined function SB-XC:DPB ; In SB!KERNEL:%LDB: Undefined function SB-XC:BYTE ; In SB!KERNEL:%LDB: Undefined function SB-XC:LDB ;Compiler warnings for "src/code/cross-byte.lisp" : ; In SB-XC:MASK-FIELD: Undefined function SB!INT:BUG ; In SB-XC:LDB: Undefined function SB!INT:BUG ;Compiler warnings for "src/code/cross-sap.lisp" : ; In SAP+: Unknown or invalid type SAP-INT, declaration ignored > Error: FAILURE-P was set when creating "obj/from-host/src/code/cross-sap.lx64fsl". > While executing: COMPILE-STEM, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Continue, using possibly bogus file "obj/from-host/src/code/cross-sap.lx64fsl" > Type :? for other options. 1 > T. 1 > > Error: Reader error on #<CCL::RECORDING-CHARACTER-INPUT-STREAM #x3020006CDA0D>, near position 1: > Unmatched ')' . > While executing: CCL::SIGNAL-READER-ERROR, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 2 > deleted #P"/home/gdr/src/sbcl.cvs/obj/from-host/src/code/cross-sap.lx64fsl-tmp" real 0m0.502s user 0m0.319s sys 0m0.023s //entering make-target-1.sh //building runtime system and symbol table file make: Entering directory `/home/gdr/src/sbcl.cvs/src/runtime' GNUmakefile:33: genesis/Makefile.features: No such file or directory make: *** No rule to make target `genesis/Makefile.features'. Stop. |
From: Nikodemus S. <nik...@ra...> - 2010-10-05 19:52:08
|
On 5 October 2010 21:59, Gabriel Dos Reis <gdr@integrable- > SBCL builds fails with Clozure CL as bootstrapping Lisp system. > Apparently, it is picky about use of undefined functions. > ;Compiler warnings for "src/code/cross-sap.lisp" : > ; In SAP+: Unknown or invalid type SAP-INT, declaration ignored >> Error: FAILURE-P was set when creating "obj/from-host/src/code/cross-sap.lx64fsl". Not functions, types. SAP-INT is defined only later in the build, in src/compiler/target/vm.lisp. Removing the SAP-INT type from cross-sap.lisp is probably the way to go, but if CCL these days considers undefined type specifiers worth a full warning, there are probably other places in the build where the issue arises too. Cheers, -- Nikodemus |
From: Faré <fa...@gm...> - 2010-10-05 20:15:20
|
On 5 October 2010 15:22, Nikodemus Siivola <nik...@ra...> wrote: > On 5 October 2010 21:59, Gabriel Dos Reis <gdr@integrable- > >> SBCL builds fails with Clozure CL as bootstrapping Lisp system. >> Apparently, it is picky about use of undefined functions. > >> ;Compiler warnings for "src/code/cross-sap.lisp" : >> ; In SAP+: Unknown or invalid type SAP-INT, declaration ignored >>> Error: FAILURE-P was set when creating "obj/from-host/src/code/cross-sap.lx64fsl". > > Not functions, types. SAP-INT is defined only later in the build, in > src/compiler/target/vm.lisp. > > Removing the SAP-INT type from cross-sap.lisp is probably the way to > go, but if CCL these days considers undefined type specifiers worth a > full warning, there are probably other places in the build where the > issue arises too. > Which version of CCL are you using? We experienced that bug at ITA, and Clozure fixed it in r14323 or so. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] If you're wrong against the dominant ideology, you'll be laughed at. If you're right against the dominant ideology, you'll be hated. |
From: Gabriel D. R. <gd...@in...> - 2010-10-06 03:09:47
|
On Tue, Oct 5, 2010 at 3:14 PM, Faré <fa...@gm...> wrote: > On 5 October 2010 15:22, Nikodemus Siivola <nik...@ra...> wrote: >> On 5 October 2010 21:59, Gabriel Dos Reis <gdr@integrable- >> >>> SBCL builds fails with Clozure CL as bootstrapping Lisp system. >>> Apparently, it is picky about use of undefined functions. >> >>> ;Compiler warnings for "src/code/cross-sap.lisp" : >>> ; In SAP+: Unknown or invalid type SAP-INT, declaration ignored >>>> Error: FAILURE-P was set when creating "obj/from-host/src/code/cross-sap.lx64fsl". >> >> Not functions, types. SAP-INT is defined only later in the build, in >> src/compiler/target/vm.lisp. >> >> Removing the SAP-INT type from cross-sap.lisp is probably the way to >> go, but if CCL these days considers undefined type specifiers worth a >> full warning, there are probably other places in the build where the >> issue arises too. >> > Which version of CCL are you using? We experienced that bug at ITA, > and Clozure fixed it in r14323 or so. most recent version from SVN -- just rebuilt a fresh image and tried again; same result. -- Gaby |
From: Gabriel D. R. <gd...@in...> - 2010-10-17 09:56:26
|
On Tue, Oct 5, 2010 at 3:14 PM, Faré <fa...@gm...> wrote: > On 5 October 2010 15:22, Nikodemus Siivola <nik...@ra...> wrote: >> On 5 October 2010 21:59, Gabriel Dos Reis <gdr@integrable- >> >>> SBCL builds fails with Clozure CL as bootstrapping Lisp system. >>> Apparently, it is picky about use of undefined functions. >> >>> ;Compiler warnings for "src/code/cross-sap.lisp" : >>> ; In SAP+: Unknown or invalid type SAP-INT, declaration ignored >>>> Error: FAILURE-P was set when creating "obj/from-host/src/code/cross-sap.lx64fsl". >> >> Not functions, types. SAP-INT is defined only later in the build, in >> src/compiler/target/vm.lisp. >> >> Removing the SAP-INT type from cross-sap.lisp is probably the way to >> go, but if CCL these days considers undefined type specifiers worth a >> full warning, there are probably other places in the build where the >> issue arises too. >> > Which version of CCL are you using? We experienced that bug at ITA, > and Clozure fixed it in r14323 or so. I am at 1.6-dev-r14121M-trunk and now I am still seeing: ? ;Compiler warnings for "src/code/backq.lisp" : ; In SB!INT:SIMPLE-READER-ERROR: Undefined function SB!INT:BUG ;Compiler warnings for "src/code/cross-misc.lisp" : ; In SB!KERNEL:%DPB: Undefined function SB-XC:BYTE ; In SB!KERNEL:%DPB: Undefined function SB-XC:DPB ; In SB!KERNEL:%LDB: Undefined function SB-XC:BYTE ; In SB!KERNEL:%LDB: Undefined function SB-XC:LDB ;Compiler warnings for "src/code/cross-byte.lisp" : ; In SB-XC:MASK-FIELD: Undefined function SB!INT:BUG ; In SB-XC:LDB: Undefined function SB!INT:BUG ;Compiler warnings for "src/code/cross-sap.lisp" : ; In SAP+: Unknown or invalid type SAP-INT, declaration ignored > Error: FAILURE-P was set when creating "obj/from-host/src/code/cross-sap.lx64fsl". -- Gaby |
From: Nikodemus S. <nik...@ra...> - 2010-10-17 11:58:42
|
On 17 October 2010 12:56, Gabriel Dos Reis <gd...@in...> wrote: >> Which version of CCL are you using? We experienced that bug at ITA, >> and Clozure fixed it in r14323 or so. > > I am at 1.6-dev-r14121M-trunk and now I am still seeing: Unless I'm mistaken r14323 > r14121, so this is not particularly surprising. Cheers, -- Nikodemus |
From: Gabriel D. R. <gd...@in...> - 2010-10-17 15:31:07
|
On Sun, Oct 17, 2010 at 6:03 AM, Nikodemus Siivola <nik...@ra...> wrote: > On 17 October 2010 12:56, Gabriel Dos Reis <gd...@in...> wrote: > >>> Which version of CCL are you using? We experienced that bug at ITA, >>> and Clozure fixed it in r14323 or so. >> >> I am at 1.6-dev-r14121M-trunk and now I am still seeing: > > Unless I'm mistaken r14323 > r14121, so this is not particularly surprising. Ooops, that was the revision number of their bootstrapping image. The actual source (and built compiler) is at revision 14367. So, I'm using a version post that mentioned by Fare. -- Gaby |
From: Nikodemus S. <nik...@ra...> - 2010-10-17 15:45:10
|
On 17 October 2010 18:30, Gabriel Dos Reis <gd...@in...> wrote: > Ooops, that was the revision number of their bootstrapping image. > The actual source (and built compiler) is at revision 14367. So, I'm > using a version post that mentioned by Fare. Ok. The thing to find out is if CCL intentionally considers forward references to types worth a full warning, or if this a regression. In the first case the build needs to be tweaked never to refer to unknown types -- or more KLUDGEly build-order.lisp-expr needs to have a few :IGNORE-FAILURE-P flags set. If this is a CCL regression, on the other hand, unless someone has the extra time and energy to sort out the types as mentioned above, we won't be building from CCL as long as the issue remains. (I at least am not motivated to add :IGNORE-FAILURE-P flags as a short-term workaround, and unless there is pressing cause I'm unlikely to sort out the forward-references to types in a hurry.) If you'd like to work on removing the forward-references to types, I'll be happy to help, though -- and others on #sbcl will probably too. Cheers, -- Nikodemus |
From: Gabriel D. R. <gd...@in...> - 2010-10-17 16:10:06
|
On Sun, Oct 17, 2010 at 10:45 AM, Nikodemus Siivola <nik...@ra...> wrote: > On 17 October 2010 18:30, Gabriel Dos Reis <gd...@in...> wrote: > >> Ooops, that was the revision number of their bootstrapping image. >> The actual source (and built compiler) is at revision 14367. So, I'm >> using a version post that mentioned by Fare. > > Ok. The thing to find out is if CCL intentionally considers forward > references to types worth a full warning, or if this a regression. OK, this is the second Lisp compiler I'm trying to use to bootstrap SBCL (on my brand new machine) and in both cases the build fails and I cannot tell who has to fix SBCL bootstrap-failing build. In normal circumstances, I would think it should be SBCL :-) I'll post the other failing bootstrap shortly. > > In the first case the build needs to be tweaked never to refer to > unknown types -- or more KLUDGEly build-order.lisp-expr needs to have > a few :IGNORE-FAILURE-P flags set. Isn't dependending on FAILURE-P a bit fragile? As far as I can tell, it essentially depends on the taste of the bootstrapping Lisp system -- which might and is regularly different from that of SBCL. CLISP, for instance, would flags stuff with FAILURE-P when SBCL would not. > > If this is a CCL regression, on the other hand, unless someone has the > extra time and energy to sort out the types as mentioned above, we > won't be building from CCL as long as the issue remains. > > (I at least am not motivated to add :IGNORE-FAILURE-P flags as a > short-term workaround, and unless there is pressing cause I'm unlikely > to sort out the forward-references to types in a hurry.) > > If you'd like to work on removing the forward-references to types, > I'll be happy to help, though -- and others on #sbcl will probably > too. My SBCL-fu is non-existent. :-/ |
From: Nikodemus S. <nik...@ra...> - 2010-10-17 16:57:42
|
On 17 October 2010 19:10, Gabriel Dos Reis <gd...@in...> wrote: > OK, this is the second Lisp compiler I'm trying to use to bootstrap > SBCL (on my brand new machine) and in both cases the build fails > and I cannot tell who has to fix SBCL bootstrap-failing build. In normal > circumstances, I would think it should be SBCL :-) Sure. However, the only bootstrap host that is currently actively tested is SBCL itself. CMUCL used to be regularly tested as well, but I'm not sure what the current situation is. Like I said, if full warning for forward-referenced type specifiers is the new official line for CCL, I'm quite willing to look at adjusting the build to account for this. Given limited time available, however, if CCL folks themselves consider this a bug -- as Faré hinted -- I'd rather not, because it isn't otherwise an issue. (And presumably CCL would then fix their bug and the build would work again.) > Isn't dependending on FAILURE-P a bit fragile? > As far as I can tell, it essentially depends on the taste of the > bootstrapping Lisp system -- which might and is regularly different > from that of SBCL. CLISP, for instance, would flags stuff with > FAILURE-P when SBCL would not. If _is_ a bit fragile if the host changes its interpretation of things, yes -- but really, maintaining a portable bootstrap is a bit fragile when hosts change their take on what is allowed and what isn't. FAILURE-P is a symptom of that more than anything. Cheers, -- Nikodemus |
From: Gabriel D. R. <gd...@in...> - 2010-10-17 17:36:37
|
On Sun, Oct 17, 2010 at 11:57 AM, Nikodemus Siivola <nik...@ra...> wrote: > On 17 October 2010 19:10, Gabriel Dos Reis <gd...@in...> wrote: > Given limited time available, however, if CCL folks themselves > consider this a bug -- as Faré hinted -- I'd rather not, because it > isn't otherwise an issue. (And presumably CCL would then fix their bug > and the build would work again.) Understood. Thanks, -- Gaby |
From: Christophe R. <cs...@ca...> - 2010-10-17 17:58:41
|
Nikodemus Siivola <nik...@ra...> writes: > On 17 October 2010 19:10, Gabriel Dos Reis <gd...@in...> wrote: > >> Isn't dependending on FAILURE-P a bit fragile? >> As far as I can tell, it essentially depends on the taste of the >> bootstrapping Lisp system -- which might and is regularly different >> from that of SBCL. CLISP, for instance, would flags stuff with >> FAILURE-P when SBCL would not. > > If _is_ a bit fragile if the host changes its interpretation of > things, yes -- but really, maintaining a portable bootstrap is a bit > fragile when hosts change their take on what is allowed and what > isn't. FAILURE-P is a symptom of that more than anything. FAILURE-P is conservative: it aborts, rather than produce something that is bogus. If you, as the user building sbcl, know better, you can always override the system's view of failure by building with the host compile in an interactive (rather than batch) mode, and choosing the continue restart for each "failing" file. Cheers, Christophe |
From: Faré <fa...@gm...> - 2010-10-18 02:24:11
|
On 17 October 2010 09:57, Nikodemus Siivola <nik...@ra...> wrote: > Like I said, if full warning for forward-referenced type specifiers is > the new official line for CCL, I'm quite willing to look at adjusting > the build to account for this. > > Given limited time available, however, if CCL folks themselves > consider this a bug -- as Faré hinted -- I'd rather not, because it > isn't otherwise an issue. (And presumably CCL would then fix their bug > and the build would work again.) > You should ask the CCL folks what is their policy. I think they agree that it's a bug that forward-referenced type specifiers should cause a warning, and it's possible that there's a bug in the implementation, but it is also possible that there will be a warning if a type remains undefined by the end of the compilation unit. Please talk to them (maybe on irc.freenode.net #ccl) and tell us what the status is. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A great civilization is not conquered from without until it destroys itself from within. — Will Durant |
From: Gabriel D. R. <gd...@in...> - 2010-10-17 17:48:34
|
On Sun, Oct 17, 2010 at 12:24 PM, Christophe Rhodes <cs...@ca...> wrote: > Nikodemus Siivola <nik...@ra...> writes: > >> On 17 October 2010 19:10, Gabriel Dos Reis <gd...@in...> wrote: >> >>> Isn't dependending on FAILURE-P a bit fragile? >>> As far as I can tell, it essentially depends on the taste of the >>> bootstrapping Lisp system -- which might and is regularly different >>> from that of SBCL. CLISP, for instance, would flags stuff with >>> FAILURE-P when SBCL would not. >> >> If _is_ a bit fragile if the host changes its interpretation of >> things, yes -- but really, maintaining a portable bootstrap is a bit >> fragile when hosts change their take on what is allowed and what >> isn't. FAILURE-P is a symptom of that more than anything. > > FAILURE-P is conservative: it aborts, rather than produce something that > is bogus. See the discussion starting at: http://sourceforge.net/mailarchive/message.php?msg_name=4C51A5F9.20502%40gnu.org > If you, as the user building sbcl, know better, you can > always override the system's view of failure by building with the host > compile in an interactive (rather than batch) mode, and choosing the > continue restart for each "failing" file. The `canonical' way to build SBCL is with make.sh, which isn't interactive. -- Gaby |
From: Nikodemus S. <nik...@ra...> - 2010-10-17 17:57:17
|
On 17 October 2010 20:48, Gabriel Dos Reis <gd...@in...> wrote: > The `canonical' way to build SBCL is with make.sh, which isn't > interactive. sh make.sh --xc-host="whatever-xc-host appropriate-args" which is to say for self-hosted builds: sh make.sh --xc-host="sbcl --no-userinit --no-sysinit" which will land you in the debugger on FAILURE-P instead of aborting the whole build. Cheers, -- Nikodemus |
From: Gabriel D. R. <gd...@in...> - 2010-10-18 23:35:20
|
On Sun, Oct 17, 2010 at 11:57 AM, Nikodemus Siivola <nik...@ra...> wrote: > On 17 October 2010 19:10, Gabriel Dos Reis <gd...@in...> wrote: > >> OK, this is the second Lisp compiler I'm trying to use to bootstrap >> SBCL (on my brand new machine) and in both cases the build fails >> and I cannot tell who has to fix SBCL bootstrap-failing build. In normal >> circumstances, I would think it should be SBCL :-) > > Sure. However, the only bootstrap host that is currently actively > tested is SBCL itself. CMUCL used to be regularly tested as well, but > I'm not sure what the current situation is. The Cl people just fixed the speecific issue we were discussing here. Thanks for talking to them. Now, I am having a different issue -- the build still fails b for a different reason I think. Here is the failure: ;Compiler warnings for "src/code/defbangstruct.lisp" : ; In JUST-DUMP-IT-NORMALLY: Unknown type STRUCTURE!OBJECT, declaration ignored ; In IGNORE-IT: Unknown type STRUCTURE!OBJECT, declaration ignored ; In MAKE-DELAYED-DEF!STRUCT: Conflicting type declarations for MISSING-ARG ;Compiler warnings for "src/code/defbangstruct.lisp" : ; In SB!KERNEL:%INSTANCE-SET: Undefined function SB!KERNEL:DSD-ACCESSOR-NAME ; In SB!KERNEL:%INSTANCE-SET: Undefined function SB!KERNEL:DD-SLOTS ; In SB!KERNEL:%INSTANCE-SET: Undefined function SB!KERNEL:LAYOUT-INFO ; In SB!KERNEL:%INSTANCE-SET: Undefined function SB!KERNEL:CLASSOID-LAYOUT ; In SB!KERNEL:%INSTANCE-SET: Undefined function SB!KERNEL:FIND-CLASSOID ; In SB!KERNEL:%INSTANCE-REF: Undefined function SB!KERNEL:DSD-ACCESSOR-NAME ; In SB!KERNEL:%INSTANCE-REF: Undefined function SB!KERNEL:DD-SLOTS ; In SB!KERNEL:%INSTANCE-REF: Undefined function SB!KERNEL:LAYOUT-INFO ; In SB!KERNEL:%INSTANCE-REF: Undefined function SB!KERNEL:CLASSOID-LAYOUT ; In SB!KERNEL:%INSTANCE-REF: Undefined function SB!KERNEL:FIND-CLASSOID ; In SB!KERNEL:%INSTANCE-LENGTH: Undefined function SB!KERNEL:FIND-CLASSOID ; In SB!KERNEL:%INSTANCE-LENGTH: Undefined function SB!KERNEL:CLASSOID-LAYOUT ; In SB!KERNEL:%INSTANCE-LENGTH: Undefined function SB!KERNEL:LAYOUT-LENGTH > Error: FAILURE-P was set when creating "obj/from-host/src/code/defbangstruct.lx64fsl". > While executing: COMPILE-STEM, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Continue, using possibly bogus file "obj/from-host/src/code/defbangstruct.lx64fsl" > Type :? for other options. 1 > T. 1 > > Error: Reader error on #<CCL::RECORDING-CHARACTER-INPUT-STREAM #x302000B99EFD>, near position 1: > Unmatched ')' . > While executing: CCL::SIGNAL-READER-ERROR, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 2 > deleted #P"/home/gdr/src/sbcl.cvs/obj/from-host/src/code/defbangstruct.lx64fsl-tmp" -- Gaby |
From: Nikodemus S. <nik...@ra...> - 2010-10-19 05:25:50
|
On 19 October 2010 02:35, Gabriel Dos Reis <gd...@in...> wrote: > Now, I am having a different issue -- the build still fails b for a > different reason I think. Here is the failure: > > ;Compiler warnings for "src/code/defbangstruct.lisp" : > ; In JUST-DUMP-IT-NORMALLY: Unknown type STRUCTURE!OBJECT, declaration ignored > ; In IGNORE-IT: Unknown type STRUCTURE!OBJECT, declaration ignored > ; In MAKE-DELAYED-DEF!STRUCT: Conflicting type declarations for MISSING-ARG > ;Compiler warnings for "src/code/defbangstruct.lisp" : > ; In SB!KERNEL:%INSTANCE-SET: Undefined function SB!KERNEL:DSD-ACCESSOR-NAME > ; In SB!KERNEL:%INSTANCE-SET: Undefined function SB!KERNEL:DD-SLOTS > ; In SB!KERNEL:%INSTANCE-SET: Undefined function SB!KERNEL:LAYOUT-INFO > ; In SB!KERNEL:%INSTANCE-SET: Undefined function SB!KERNEL:CLASSOID-LAYOUT > ; In SB!KERNEL:%INSTANCE-SET: Undefined function SB!KERNEL:FIND-CLASSOID > ; In SB!KERNEL:%INSTANCE-REF: Undefined function SB!KERNEL:DSD-ACCESSOR-NAME > ; In SB!KERNEL:%INSTANCE-REF: Undefined function SB!KERNEL:DD-SLOTS > ; In SB!KERNEL:%INSTANCE-REF: Undefined function SB!KERNEL:LAYOUT-INFO > ; In SB!KERNEL:%INSTANCE-REF: Undefined function SB!KERNEL:CLASSOID-LAYOUT > ; In SB!KERNEL:%INSTANCE-REF: Undefined function SB!KERNEL:FIND-CLASSOID > ; In SB!KERNEL:%INSTANCE-LENGTH: Undefined function SB!KERNEL:FIND-CLASSOID > ; In SB!KERNEL:%INSTANCE-LENGTH: Undefined function SB!KERNEL:CLASSOID-LAYOUT > ; In SB!KERNEL:%INSTANCE-LENGTH: Undefined function SB!KERNEL:LAYOUT-LENGTH >> Error: FAILURE-P was set when creating "obj/from-host/src/code/defbangstruct.lx64fsl". This > ; In MAKE-DELAYED-DEF!STRUCT: Conflicting type declarations for MISSING-ARG is the actual issue and that this #+sb-xc-host (eval-when (:compile-toplevel :load-toplevel :execute) ;; a description of a DEF!STRUCT call to be stored until we get ;; enough of the system running to finish processing it (defstruct delayed-def!struct (args (missing-arg) :type cons) (package (sane-package) :type package)) is the source, but since MISSING-ARG has been declared as (declaim (ftype (function () nil) missing-arg)) the complaint seems to be bogus. I've reported this to Clozure as http://trac.clozure.com/ccl/ticket/764 Question: do you want to build SBCL with CCL, or just build SBCL? If your heart is set on using CCL, than given the current state of affairs you need to get into figuring out the causes of build failures (such as the one above) yourself -- and either working around them in the SBCL source, or reporting them to CCL folks, or both -- whatever seems appropriate. If building SBCL in general is the primary goal, than bootstrapping from CCL is clearly not the way to go about it at the moment. Hosting on SBCL itself or CMUCL is likely to be less painful. Cheers, -- Nikodemus |
From: Gabriel D. R. <gd...@in...> - 2010-10-19 06:08:09
|
On Tue, Oct 19, 2010 at 12:25 AM, Nikodemus Siivola <nik...@ra...> wrote: > On 19 October 2010 02:35, Gabriel Dos Reis <gd...@in...> wrote: >>> Error: FAILURE-P was set when creating "obj/from-host/src/code/defbangstruct.lx64fsl". > > This > >> ; In MAKE-DELAYED-DEF!STRUCT: Conflicting type declarations for MISSING-ARG > > is the actual issue and that this > > #+sb-xc-host > (eval-when (:compile-toplevel :load-toplevel :execute) > ;; a description of a DEF!STRUCT call to be stored until we get > ;; enough of the system running to finish processing it > (defstruct delayed-def!struct > (args (missing-arg) :type cons) > (package (sane-package) :type package)) > > is the source, but since MISSING-ARG has been declared as > > (declaim (ftype (function () nil) missing-arg)) > > the complaint seems to be bogus. I've reported this to Clozure as > > http://trac.clozure.com/ccl/ticket/764 > > Question: do you want to build SBCL with CCL, or just build SBCL? I would like to build SBCL (if possible, from something like either CCL or ECL.) on both Windows and *nix systems. But using the prebuilt SBCL binaries isn't really an option (for various reasons.) CLISP is not an option. > > If your heart is set on using CCL, than given the current state of > affairs you need to get into figuring out the causes of build failures > (such as the one above) yourself -- and either working around them in > the SBCL source, or reporting them to CCL folks, or both -- whatever > seems appropriate. I am not particularly attached to CCL (I am a bit to SBCL though :-) but it is currently the only Lisp systems that seems to have a pretty "simple" bootstrapping system that starts form a C compiler and on the major platforms I have access to and that I care about. SBCL is a good system that I like to use to test OpenAxiom, but its demand on an existing Lisp system to build it actually imposes more hurdles that it ought to be :-/ ECL is my other option, but I am under the impression nobody cares about it as a bootstrapping system for SBCL. Of course, I would be fiddling with SBCL source codes if I were a bit familiar with it -- it looks a bit impenetrable to me... The INSTALL file lists CCL as a supported bootstrapping Lisp. So, I thought you would want to know when there are build problems with it. But, if the new position is that is no longer the case, well I would just discount it (and maybe you would want to update the INSTALL file to avoid being innonded by build failure reports.) > > If building SBCL in general is the primary goal, than bootstrapping > from CCL is clearly not the way to go about it at the moment. Hosting > on SBCL itself or CMUCL is likely to be less painful. -- Gaby |
From: Nikodemus S. <nik...@ra...> - 2010-10-19 07:37:48
|
On 19 October 2010 09:08, Gabriel Dos Reis <gd...@in...> wrote: > I would like to build SBCL (if possible, from something like either > CCL or ECL.) on both Windows and *nix systems. But using the > prebuilt SBCL binaries isn't really an option (for various reasons.) > CLISP is not an option. Then you need to either time-travel back far enough to find a CCL/OpenMCL you can use to bootstrap (I *used* to work), wait till CCL fixes the bugs that stop the build, or tweak the build to work around those issues. (Or find someone who can do this for you.) > I am not particularly attached to CCL (I am a bit to SBCL though :-) > but it is currently the only Lisp systems that seems to have a pretty > "simple" bootstrapping system that starts form a C compiler and on > the major platforms I have access to and that I care about. SBCL is This is not actually true, as far as I understand it. Someone with better knowledge of CCL should feel free to correct me, but I'm reasonably certain it does NOT bootstrap from the C-compiler, but rather the sources come with a bootstrap binary included. In terms of using binaries you haven't built yourself, starting from CCL is no better than grabbing an SBCL binary to start with. If you must bootstrap from plain C, then using Clisp (after finding a version that works to bootstrap SBCL) is your perhaps you bet right now. I'd be delighted to merge patches to support ECL as a host, but I don't have the time to work on that myself. ABCL is another viable option: at least at some point the ABCL folks used building SBCL as part of their regression tests. Also, if you could expand a bit on your reasons not to use SBCL binary to bootstrap, perhaps other solutions could be devised. Right now the constraints you operate under are a bit impenetrable to me, so it's hard to provide appropriate advice. > The INSTALL file lists CCL as a supported bootstrapping Lisp. So, I > thought you would want to know when there are build problems with it. Supported... as long as the build problems are ours, not theirs. Which is pretty much the stance on all non-SBCL build hosts. In an ideal world we'd like to support more of them and better, but given the resources available ... *sigh*. We should update the INSTALL file to reflect the current state of affairs better, yes. Cheers, -- Nikodemus |
From: Gabriel D. R. <gd...@in...> - 2010-10-19 08:06:39
|
On Tue, Oct 19, 2010 at 2:37 AM, Nikodemus Siivola <nik...@ra...> wrote: > On 19 October 2010 09:08, Gabriel Dos Reis <gd...@in...> wrote: >> I am not particularly attached to CCL (I am a bit to SBCL though :-) >> but it is currently the only Lisp systems that seems to have a pretty >> "simple" bootstrapping system that starts form a C compiler and on >> the major platforms I have access to and that I care about. SBCL is > > This is not actually true, as far as I understand it. Someone with > better knowledge of CCL should feel free to correct me, but I'm > reasonably certain it does NOT bootstrap from the C-compiler, but > rather the sources come with a bootstrap binary included. You can bootstrap from the included image, or you can build a kernel using a C compiler, and then use that kernel to build the rest of the system. See http://openmcl.clozure.com/ccl-documentation.html#Building-the-kernel > In terms of using binaries you haven't built yourself, starting from > CCL is no better than grabbing an SBCL binary to start with. > > If you must bootstrap from plain C, then using Clisp (after finding a > version that works to bootstrap SBCL) is your perhaps you bet right > now. I'd be delighted to merge patches to support ECL as a host, but I > don't have the time to work on that myself. The recent restructuring of SBCL bootstrapping process also removed some of the kludges needed for ECL. However, at the moment, bootstrapping with ECL fails because of some purported undefined function -- which I'm pretty sure is defined. See my other mail. What I am unsure about is whether this is one of those cases where ECL's approach of not "dumping" images (therefore not inadvertantly retaining some function definitions) is exposing a "logic" bug in SBCL, or whether it is just plain bug in ECL. I had reported the issue to ECL people too. > ABCL is another viable option: at least at some point the ABCL folks > used building SBCL as part of their regression tests. > > Also, if you could expand a bit on your reasons not to use SBCL binary > to bootstrap, perhaps other solutions could be devised. Right now the > constraints you operate under are a bit impenetrable to me, so it's > hard to provide appropriate advice. On *nix, I'm using a build farm where I do not have much control on installing prebuilt binaries -- so, except GCC and other core tools, I need (as part of the build process) to build SBCL from source. -- Gaby |
From: Nikodemus S. <nik...@ra...> - 2010-10-19 08:59:57
|
On 19 October 2010 11:06, Gabriel Dos Reis <gd...@in...> wrote: > You can bootstrap from the included image, or you can build a kernel > using a C compiler, and then use that kernel to build the rest of the > system. See > > http://openmcl.clozure.com/ccl-documentation.html#Building-the-kernel Right, except that the "kernel" is like "runtime" in SBCL. It doesn't contain the compiler, or most anything else. Those are in the "image", called "core" in SBCL. The included heap image is the lisp binary in all meaningful senses of the word, _except_ in the sense of "binary executable by the OS". The kernel essentially mmaps the image and jumps in there -- and the image calls back to the kernel when it wants to eg. collect garbage. > What I am unsure about is whether this is one of those cases where > ECL's approach of not "dumping" images (therefore not inadvertantly > retaining some function definitions) is exposing a "logic" bug in The build process by default does not dump a host image, so ECL's eccentricities in that respect should not be an issue. > On *nix, I'm using a build farm where I do not have much control on > installing prebuilt binaries -- so, except GCC and other core tools >, I need (as part of the build process) to build SBCL from source. What's stopping you from downloading a binary in addition to the sources? You don't need to install it to run it. Eg. for OS X: wget http://prdownloads.sourceforge.net/sbcl/sbcl-1.0.29-x86-darwin-binary-r2.tar.bz2 tar -jxvf sbcl-1.0.29-x86-darwin-binary-r2.tar.bz2 wget http://prdownloads.sourceforge.net/sbcl/sbcl-1.0.43-source.tar.bz2?download tar -jxvf sbcl-1.0.43-source.tar.bz2 cd sbcl-1.0.43 sh make.sh --xc-host="sh ../sbcl-1.0.29-x86-darwin/run-sbcl.sh --no-userinit --disable-debugger" No installed SBCL required. I feel like I'm missing something there. Doing this is morally equivalent to bootstrapping CCL from the source-tarball with the included kernel and image. Cheers, -- Nikodemus |
From: Gabriel D. R. <gd...@in...> - 2010-10-19 12:01:26
|
On Tue, Oct 19, 2010 at 3:59 AM, Nikodemus Siivola <nik...@ra...> wrote: > On 19 October 2010 11:06, Gabriel Dos Reis <gd...@in...> wrote: > > What's stopping you from downloading a binary in addition to the > sources? You don't need to install it to run it. > > No installed SBCL required. I feel like I'm missing something there. This: > Eg. for OS X: > > wget http://prdownloads.sourceforge.net/sbcl/sbcl-1.0.29-x86-darwin-binary-r2.tar.bz2 > > tar -jxvf sbcl-1.0.29-x86-darwin-binary-r2.tar.bz2 > > wget http://prdownloads.sourceforge.net/sbcl/sbcl-1.0.43-source.tar.bz2?download > > tar -jxvf sbcl-1.0.43-source.tar.bz2 > > cd sbcl-1.0.43 > > sh make.sh --xc-host="sh ../sbcl-1.0.29-x86-darwin/run-sbcl.sh > --no-userinit --disable-debugger" > If either the INSTALL file or the documentation has that, it would save you the trouble of repeating it and the next user from having to discover it only after a prolonger discussion. The way INSTALL is currently written leaves the mistaken impression that above won't work. Thanks. -- Gaby |