From: <wil...@ai...> - 2008-04-24 20:43:44
|
Schemes are being made to replace me but probably next week-ish, not tomorrow-ish. Thus I intend to do one last routine release, sbcl-1.0.17, in about five days. So today is the 20th :-|, albeit delayed by some fraction of the delay in the release of sbcl-1.0.16. And as usual, please test vigorously and patch conservatively until release. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: Rex D. <rd...@ma...> - 2008-04-25 12:20:06
|
William Harold Newman wrote: > Schemes are being made to replace me but probably next week-ish, not > tomorrow-ish. Thus I intend to do one last routine release, > sbcl-1.0.17, in about five days. Has anyone been able to successfully build sbcl against a recent glibc/gcc (2.8, 4.3.0 respectively)? I haven't: http://thread.gmane.org/gmane.lisp.steel-bank.devel/10963/focus=10965 In particular, the following contribs fail to build/run properly: asdf-instalL, sb-simple-streams I've got a machine that I can give any interested sbcl developer a remote shell/login to help figure out what's going wrong. -- Rex |
From: Christophe R. <cs...@ca...> - 2008-04-25 13:04:44
|
Rex Dieter <rd...@ma...> writes: > William Harold Newman wrote: > >> Schemes are being made to replace me but probably next week-ish, not >> tomorrow-ish. Thus I intend to do one last routine release, >> sbcl-1.0.17, in about five days. > > Has anyone been able to successfully build sbcl against a recent glibc/gcc > (2.8, 4.3.0 respectively)? I haven't: > http://thread.gmane.org/gmane.lisp.steel-bank.devel/10963/focus=10965 > > In particular, the following contribs fail to build/run properly: > asdf-instalL, sb-simple-streams > > I've got a machine that I can give any interested sbcl developer a remote > shell/login to help figure out what's going wrong. Can you find the areas in the build logs where those contrib systems are built or tested, and identify the problem like that? Alternatively, what happens when you try to run the SBCL self-tests (with cd tests && sh ./run-tests.sh)? Thanks, Christophe |
From: Rex D. <rd...@ma...> - 2008-04-25 13:19:40
|
Christophe Rhodes wrote: > Rex Dieter <rd...@ma...> writes: > >> William Harold Newman wrote: >> >>> Schemes are being made to replace me but probably next week-ish, not >>> tomorrow-ish. Thus I intend to do one last routine release, >>> sbcl-1.0.17, in about five days. >> Has anyone been able to successfully build sbcl against a recent glibc/gcc >> (2.8, 4.3.0 respectively)? I haven't: >> http://thread.gmane.org/gmane.lisp.steel-bank.devel/10963/focus=10965 >> >> In particular, the following contribs fail to build/run properly: >> asdf-instalL, sb-simple-streams >> >> I've got a machine that I can give any interested sbcl developer a remote >> shell/login to help figure out what's going wrong. > > Can you find the areas in the build logs where those contrib systems > are built or tested, and identify the problem like that? First red flag is a huge traceback on trying to build asdf-install: unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "initial thread" {A6EB399}>: Error during processing of --eval option (LOAD #P"../asdf-stub.lisp"): The variable SB-BSD-SOCKETS-INTERNAL::EAI-NODATA is unbound. 0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {BD69D0D}>)[:EXTERNAL] 1: (SB-DEBUG:BACKTRACE 128 #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {90B28C9}>) 2: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SIMPLE-ERROR {BD68211}> #<unavailable argument>) 3: (INVOKE-DEBUGGER #<SIMPLE-ERROR {BD68211}>) 4: (INVOKE-DEBUGGER #<SIMPLE-ERROR {BD68211}>)[:EXTERNAL] 5: (ERROR "Error during processing of --eval ~ option ~S:~%~% ~A")[:EXTERNAL] 6: ((LAMBDA (SB-IMPL::E)) #<UNBOUND-VARIABLE EAI-NODATA {BD680F9}>) 7: ((LAMBDA (SB-IMPL::E)) #<UNBOUND-VARIABLE EAI-NODATA {BD680F9}>)[:EXTERNAL] 8: (SIGNAL #<UNBOUND-VARIABLE EAI-NODATA {BD680F9}>)[:EXTERNAL] 9: (ERROR UNBOUND-VARIABLE)[:EXTERNAL] 10: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB7CABFE0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB7CABCCC :TYPE (* (SB-ALIEN:STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14)) 11: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB7CABFE0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB7CABCCC :TYPE (* (SB-ALIEN:STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EXTERNAL] 12: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB7CABCCC) #<unavailable argument>) 13: ("foreign function: #x806074C") 14: ("foreign function: #x8050CCC") 15: ("foreign function: #x8054987") 16: (SYMBOL-VALUE SB-BSD-SOCKETS-INTERNAL::EAI-NODATA) 17: (SB-FASL::FOP-FUNCALL) 18: (SB-FASL::LOAD-FASL-GROUP #<SB-SYS:FD-STREAM for "file ~/cvs.fedoraproject.org/sbcl/devel/sbcl-1.0.16/contrib/sb-bsd-sockets/name-service.fasl" {BCB1A09}>) 19: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 20: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]520)) 21: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK) {B7CAC18D}> #S(SB-THREAD:MUTEX :NAME "big compiler lock" :%OWNER #<SB-THREAD:THREAD "initial thread" {A6EB399}> :STATE 1)) 22: (SB-FASL::LOAD-AS-FASL #<SB-SYS:FD-STREAM for "file ~/cvs.fedoraproject.org/sbcl/devel/sbcl-1.0.1 6/contrib/sb-bsd-sockets/name-service.fasl" {BCB1A09}> NIL #<unavailable argument>) 23: (SB-FASL::%LOAD #<SB-SYS:FD-STREAM for "file ~/cvs.fedoraproject.org/sbcl/devel/sbcl-1.0.16/contrib/sb-bsd-sockets/name-service.fasl" {BCB1A09}>)[:EXTERNAL] 24: (SB-FASL::%LOAD #P"SYS:CONTRIB;SB-BSD-SOCKETS;NAME-SERVICE.FASL.NEWEST")[:EXTERNAL] 25: (LOAD #P"SYS:CONTRIB;SB-BSD-SOCKETS;NAME-SERVICE.FASL.NEWEST")[:EXTERNAL] 26: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:LOAD-OP ASDF:CL-SOURCE-FILE)) #<unavailable argument> #<unavailable argument> #<ASDF:LOAD-OP NIL {AC0F931}> #<ASDF:CL-SOURCE-FILE "name-service" {B55D961}>) 27: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<ASDF:LOAD-OP NIL {AC0F931}> #<ASDF:CL-SOURCE-FILE "name-service" {B55D961}>) 28: ((LAMBDA ())) 29: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 30: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]520)) 31: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK) {B7CAC7ED}> #S(SB-THREAD:MUTEX :NAME "big compiler lock" :%OWNER #<SB-THREAD:THREAD "initial thread" {A6EB399}> :STATE 1)) 32: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {A80676D}>)[:EXTERNAL] 33: (ASDF:OPERATE ASDF:LOAD-OP "asdf-install")[:EXTERNAL] 34: ((LAMBDA ())) 35: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LET ((ASDF:*CENTRAL-REGISTRY* NIL)) (PUSH :SB-BUILDING-CONTRIB *FEATURES*) (ASDF:OPERATE 'ASDF:LOAD-OP COMMON-LISP-USER::*SYSTEM*) (LET ((COMMON-LISP-USER::STUB (MAKE-PATHNAME :NAME COMMON-LISP-USER::*SYSTEM* :TYPE "lisp"))) (WHEN (PROBE-FILE (COMPILE-FILE-PATHNAME COMMON-LISP-USER::STUB)) (ERROR "fasl file exists")) (WITH-OPEN-FILE (COMMON-LISP-USER::S COMMON-LISP-USER::STUB :DIRECTION :OUTPUT :IF-EXISTS :ERROR) (PRINT '(UNLESS (MEMBER "ASDF" *MODULES* :TEST #'STRING=) (REQUIRE :ASDF)) COMMON-LISP-USER::S) (PRINT `(LET ((ASDF:*CENTRAL-REGISTRY* NIL)) (ASDF::MODULE-PROVIDE-ASDF ,COMMON-LISP-USER::*SYSTEM*)) COMMON-LISP-USER::S)) (COMPILE-FILE COMMON-LISP-USER::STUB) (DELETE-FILE COMMON-LISP-USER::STUB))) #<NULL-LEXENV>) 36: (SB-FASL::LOAD-AS-SOURCE #<SB-SYS:FD-STREAM for "file ~/cvs.fedoraproject.org/sbcl/devel/sbcl-1.0.16/contrib/asdf-install/../asdf-stub.lisp" {A6F4EA9}> NIL NIL) 37: (SB-FASL::%LOAD #<SB-SYS:FD-STREAM for "file ~/cvs.fedoraproject.org/sbcl/devel/sbcl-1.0.16/contrib/asdf-install/../asdf-stub.lisp" {A6F4EA9}>)[:EXTERNAL] 38: (SB-FASL::%LOAD #P"../asdf-stub.lisp")[:EXTERNAL] 39: (LOAD #P"../asdf-stub.lisp")[:EXTERNAL] 40: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LOAD #P"../asdf-stub.lisp") #<NULL-LEXENV>) 41: (SB-IMPL::PROCESS-EVAL-OPTIONS ((SB-EXT:DISABLE-DEBUGGER) "(defvar *system* \"asdf-install\")" (LOAD #P"../asdf-stub.lisp") "(quit)")) 42: (SB-IMPL::TOPLEVEL-INIT) 43: ((LABELS SB-IMPL::RESTART-LISP)) unhandled condition in --disable-debugger mode, quitting ; ; compilation unit aborted ; caught 1 fatal ERROR condition ; printed 319 notes + exit 2 make[1]: *** [all] Error 1 make[1]: Leaving directory `~/cvs.fedoraproject.org/sbcl/devel/sbcl-1.0.16/contrib/asdf-install' > Alternatively, what happens when you try to run the SBCL self-tests > (with cd tests && sh ./run-tests.sh)? I omitted run-tests.sh in recent builds, due to room.test.sh hanging. I'll re-build with run-tests enabled, and see. -- Rex |
From: Christophe R. <cs...@ca...> - 2008-04-25 13:28:09
|
Rex Dieter <rd...@ma...> writes: > Christophe Rhodes wrote: >> Can you find the areas in the build logs where those contrib systems >> are built or tested, and identify the problem like that? > > First red flag is a huge traceback on trying to build asdf-install: > > unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "initial thread" > {A6EB399}>: > Error during processing of --eval option (LOAD #P"../asdf-stub.lisp"): > > The variable SB-BSD-SOCKETS-INTERNAL::EAI-NODATA is unbound. I see references on the Interweb that EAI_NODATA is deprecated; on a brief check, it's rather quieter about what it has been replaced with (i.e. what getaddrinfo() returns if there is no address associated with a given name, and whether that'd distinct from what happens if there's no entry for that name in the host lookup databases). Anyone know? Best, Christophe |
From: Rex D. <rd...@ma...> - 2008-04-25 13:35:57
|
Christophe Rhodes wrote: > Rex Dieter <rd...@ma...> writes: > >> Christophe Rhodes wrote: >>> Can you find the areas in the build logs where those contrib systems >>> are built or tested, and identify the problem like that? >> >> First red flag is a huge traceback on trying to build asdf-install: >> >> unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "initial thread" >> {A6EB399}>: >> Error during processing of --eval option (LOAD #P"../asdf-stub.lisp"): >> >> The variable SB-BSD-SOCKETS-INTERNAL::EAI-NODATA is unbound. > > I see references on the Interweb that EAI_NODATA is deprecated; on a > brief check, it's rather quieter about what it has been replaced with > (i.e. what getaddrinfo() returns if there is no address associated > with a given name, and whether that'd distinct from what happens if > there's no entry for that name in the host lookup databases). Anyone > know? Looking at netdb.h on my box, includes: /* Error values for `getaddrinfo' function. */ ... # ifdef __USE_GNU # define EAI_NODATA -5 /* No address associated with NAME. */ # define EAI_ADDRFAMILY -9 /* Address family for NAME not supported. */ # define EAI_INPROGRESS -100 /* Processing request in progress. */ # define EAI_CANCELED -101 /* Request canceled. */ # define EAI_NOTCANCELED -102 /* Request not canceled. */ # define EAI_ALLDONE -103 /* All requests done. */ # define EAI_INTR -104 /* Interrupted by a signal. */ # define EAI_IDN_ENCODE -105 /* IDN encoding failed. */ # endif So looks like it's available only if _GNU_SOURCE is defined (which implies -> __USE_GNU). -- Rex |
From: Rex D. <rd...@ma...> - 2008-04-25 14:45:58
Attachments:
sbcl-1.0.16-GNU_SOURCE.patch
|
Rex Dieter wrote: > Christophe Rhodes wrote: >>> The variable SB-BSD-SOCKETS-INTERNAL::EAI-NODATA is unbound. >> >> I see references on the Interweb that EAI_NODATA is deprecated; on a >> brief check, it's rather quieter about what it has been replaced with >> (i.e. what getaddrinfo() returns if there is no address associated >> with a given name, and whether that'd distinct from what happens if >> there's no entry for that name in the host lookup databases). Anyone >> know? > > Looking at netdb.h on my box, includes: > /* Error values for `getaddrinfo' function. */ > ... > # ifdef __USE_GNU > # define EAI_NODATA -5 /* No address associated with NAME. */ > # define EAI_ADDRFAMILY -9 /* Address family for NAME not supported. > */ > # define EAI_INPROGRESS -100 /* Processing request in progress. */ > # define EAI_CANCELED -101 /* Request canceled. */ > # define EAI_NOTCANCELED -102 /* Request not canceled. */ > # define EAI_ALLDONE -103 /* All requests done. */ > # define EAI_INTR -104 /* Interrupted by a signal. */ > # define EAI_IDN_ENCODE -105 /* IDN encoding failed. */ > # endif > > So looks like it's available only if _GNU_SOURCE is defined (which > implies -> __USE_GNU). Looks like a small patch (attached) helps here. build gets further... run-tests still chugging. -- Rex |
From: Rex D. <rd...@ma...> - 2008-04-25 14:54:21
|
Rex Dieter wrote: >> Looking at netdb.h on my box, includes: >> /* Error values for `getaddrinfo' function. */ >> ... >> # ifdef __USE_GNU >> # define EAI_NODATA -5 /* No address associated with NAME. */ >> # define EAI_ADDRFAMILY -9 /* Address family for NAME not supported. >> */ >> # define EAI_INPROGRESS -100 /* Processing request in progress. */ >> # define EAI_CANCELED -101 /* Request canceled. */ >> # define EAI_NOTCANCELED -102 /* Request not canceled. */ >> # define EAI_ALLDONE -103 /* All requests done. */ >> # define EAI_INTR -104 /* Interrupted by a signal. */ >> # define EAI_IDN_ENCODE -105 /* IDN encoding failed. */ >> # endif >> >> So looks like it's available only if _GNU_SOURCE is defined (which >> implies -> __USE_GNU). > > Looks like a small patch (attached) helps here. build gets further... > run-tests still chugging. and run-tests passed! yay. -- Rex |
From: Juho S. <js...@ik...> - 2008-04-28 02:17:43
|
wil...@ai... (William Harold Newman) writes: > Schemes are being made to replace me but probably next week-ish, not > tomorrow-ish. Thus I intend to do one last routine release, > sbcl-1.0.17, in about five days. > > So today is the 20th :-|, albeit delayed by some fraction of the delay > in the release of sbcl-1.0.16. And as usual, please test vigorously > and patch conservatively until release. Would it be better to skip the release completely this month? There weren't very many changes due to the long freeze, and apparently at least two regressions (1.0.16.5, 1.0.16.11). -- Juho Snellman |
From: <wil...@ai...> - 2008-04-29 00:29:29
|
On Mon, Apr 28, 2008 at 05:18:05AM +0300, Juho Snellman wrote: > wil...@ai... (William Harold Newman) writes: > > Schemes are being made to replace me but probably next week-ish, not > > tomorrow-ish. Thus I intend to do one last routine release, > > sbcl-1.0.17, in about five days. > > > > So today is the 20th :-|, albeit delayed by some fraction of the delay > > in the release of sbcl-1.0.16. And as usual, please test vigorously > > and patch conservatively until release. > > Would it be better to skip the release completely this month? There > weren't very many changes due to the long freeze, and apparently at > least two regressions (1.0.16.5, 1.0.16.11). Yes, you're very likely right. Like you, I have less than the usual enthusiasm for the state of the snapshot that exists at the moment. I think a stable timeboxing policy has worked well, so I was going to release anyway. And once you made me think about it, any policy stability at this moment would be only superficial: after switching organizational forms and figuring out what sbcl-1.1 release should be, then things can settle down again, to whatever. So unless there's some unreasonably-long stall in the replace-me process, I'll just leave things alone for my successors to sort out. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C It might look like I'm standing motionless, but I'm actively waiting for our problems to go away. -- Bob the dinosaur |