From: Harald Hanche-O. <ha...@ma...> - 2010-01-24 17:42:52
|
Building sbcl failed yesterday: WARNING! Some of the contrib modules did not build successfully or pass their self-tests. Failed contribs:" asdf-install sb-aclrepl sb-bsd-sockets sb-cltl2 sb-cover sb-grovel sb-introspect sb-md5 sb-posix sb-queue sb-rt sb-simple-streams This is on Intel Mac OS X 10.5.8, building with sbcl 1.0.33.30. The following backtrace extracted from the log seems representative of the problem. ; loading system definition from ; /local/src/lisp/sbcl/sbcl-git/contrib/sb-bsd-sockets/sb-bsd-sockets.asd/ into ; #<PACKAGE "ASDF0"> unhandled SB-INT:SIMPLE-FILE-ERROR: failed to find the TRUENAME of /local/src/lisp/sbcl/sbcl-git/contrib/sb-grovel/sb-grovel.asd/defpackage.lisp: Not a directory 0: (SB-DEBUG::MAP-BACKTRACE #<CLOSURE (LAMBDA #) {1002CC9759}>)[:EXTERNAL] 1: (SB-DEBUG:BACKTRACE 128 #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {10000E7A61}>) 2: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SB-INT:SIMPLE-FILE-ERROR {1002CC64E1}> #<unavailable argument>) 3: (SB-DEBUG::RUN-HOOK SB-EXT:*INVOKE-DEBUGGER-HOOK* #<SB-INT:SIMPLE-FILE-ERROR {1002CC64E1}>) 4: (INVOKE-DEBUGGER #<SB-INT:SIMPLE-FILE-ERROR {1002CC64E1}>) 5: (ERROR SB-INT:SIMPLE-FILE-ERROR)[:EXTERNAL] 6: (SB-IMPL::SIMPLE-FILE-PERROR "failed to find the TRUENAME of ~A" #P"/local/src/lisp/sbcl/sbcl-git/contrib/sb-grovel/sb-grovel.asd/defpackage.lisp" 20) 7: ((FLET SB-IMPL::FAIL) "failed to find the TRUENAME of ~A" #P"/local/src/lisp/sbcl/sbcl-git/contrib/sb-grovel/sb-grovel.asd/defpackage.lisp" 20) 8: (SB-IMPL::QUERY-FILE-SYSTEM #P"/local/src/lisp/sbcl/sbcl-git/contrib/sb-grovel/sb-grovel.asd/defpackage.lisp" :TRUENAME T) 9: (TRUENAME #P"/local/src/lisp/sbcl/sbcl-git/contrib/sb-grovel/sb-grovel.asd/defpackage.lisp") 10: ((FLET SB-C::TRY-WITH-TYPE) #P"/local/src/lisp/sbcl/sbcl-git/contrib/sb-grovel/sb-grovel.asd/defpackage.lisp" "lisp" T) 11: (SB-C::VERIFY-SOURCE-FILE #P"/local/src/lisp/sbcl/sbcl-git/contrib/sb-grovel/sb-grovel.asd/defpackage.lisp") 12: (SB-C::VERIFY-SOURCE-FILE #P"/local/src/lisp/sbcl/sbcl-git/contrib/sb-grovel/sb-grovel.asd/defpackage.lisp")[:EXTERNAL] 13: (COMPILE-FILE #P"/local/src/lisp/sbcl/sbcl-git/contrib/sb-grovel/sb-grovel.asd/defpackage.lisp")[:EXTERNAL] 14: ((SB-PCL::FAST-METHOD PERFORM (COMPILE-OP CL-SOURCE-FILE)) #<unavailable argument> #<unavailable argument> #<COMPILE-OP NIL {1002B7C321}> #<CL-SOURCE-FILE "defpackage" {1002AD5F11}>) 15: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<COMPILE-OP NIL {1002B7C321}> #<CL-SOURCE-FILE "defpackage" {1002AD5F11}>) 16: ((SB-PCL::FAST-METHOD PERFORM AROUND (COMPILE-OP CL-SOURCE-FILE)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<CLOSURE # {1002CB3219}> :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2)) #<COMPILE-OP NIL {1002B7C321}> #<CL-SOURCE-FILE "defpackage" {1002AD5F11}>) 17: ((LAMBDA ())) 18: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 19: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {1002C113B9}>)[:EXTERNAL] 20: (OPERATE LOAD-OP :SB-GROVEL)[:EXTERNAL] 21: (ASDF::MODULE-PROVIDE-ASDF :SB-GROVEL) 22: ((LAMBDA (#:G[REQUIRE]13)) ASDF::MODULE-PROVIDE-ASDF) 23: (SB-IMPL::%MAP-FOR-EFFECT-ARITY-1 #<CLOSURE (LAMBDA #) {100349FD89}> (ASDF::MODULE-PROVIDE-ASDF SB-IMPL::MODULE-PROVIDE-CONTRIB)) 24: (REQUIRE :SB-GROVEL NIL) 25: (SB-INT:SIMPLE-EVAL-IN-LEXENV (REQUIRE :SB-GROVEL) #<NULL-LEXENV>) 26: (SB-INT:SIMPLE-EVAL-IN-LEXENV (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (REQUIRE :SB-GROVEL)) #<NULL-LEXENV>) 27: (SB-FASL::LOAD-AS-SOURCE #<SB-SYS:FD-STREAM for "file /local/src/lisp/sbcl/sbcl-git/contrib/sb-bsd-sockets/sb-bsd-sockets.asd" {100349C001}> NIL NIL) 28: ((FLET SB-FASL::LOAD-STREAM) #<SB-SYS:FD-STREAM for "file /local/src/lisp/sbcl/sbcl-git/contrib/sb-bsd-sockets/sb-bsd-sockets.asd" {100349C001}> NIL) 29: (LOAD #P"/local/src/lisp/sbcl/sbcl-git/contrib/sb-bsd-sockets/sb-bsd-sockets.asd/")[:EXTERNAL] 30: (FIND-SYSTEM "sb-bsd-sockets" NIL) 31: ((SB-PCL::FAST-METHOD FIND-COMPONENT ((EQL NIL) T)) #<unused argument> #<unused argument> #<unused argument> "sb-bsd-sockets" NIL) 32: ((LABELS ASDF::DO-ONE-DEP) COMPILE-OP ASDF-INSTALL-SYSTEM::SB-BSD-SOCKETS NIL) 33: ((LABELS ASDF::DO-DEP) COMPILE-OP (ASDF-INSTALL-SYSTEM::SB-BSD-SOCKETS ASDF-INSTALL-SYSTEM::SB-POSIX)) 34: ((SB-PCL::FAST-METHOD ASDF::TRAVERSE (OPERATION COMPONENT)) #(3 NIL) #<unavailable argument> #<COMPILE-OP NIL {100348BD51}> #<SYSTEM "asdf-install" {1002FE3781}>) 35: ((LABELS ASDF::DO-ONE-DEP) COMPILE-OP "asdf-install" NIL) 36: ((LABELS ASDF::DO-DEP) COMPILE-OP ("asdf-install")) 37: ((SB-PCL::FAST-METHOD ASDF::TRAVERSE (OPERATION COMPONENT)) #(3 NIL) #<unavailable argument> #<LOAD-OP NIL {1002D8BA11}> #<SYSTEM "asdf-install" {1002FE3781}>) 38: (OPERATE LOAD-OP :ASDF-INSTALL)[:EXTERNAL] 39: (SB-INT:SIMPLE-EVAL-IN-LEXENV (OPERATE 'LOAD-OP :ASDF-INSTALL) #<NULL-LEXENV>) 40: (SB-EXT:INTERACTIVE-EVAL (OPERATE 'LOAD-OP :ASDF-INSTALL))[:EXTERNAL] 41: (SB-IMPL::REPL-FUN NIL) 42: ((LAMBDA ())) 43: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {1002D85959}>) 44: (SB-IMPL::TOPLEVEL-REPL NIL) 45: (SB-IMPL::TOPLEVEL-INIT) 46: ((LABELS SB-IMPL::RESTART-LISP)) |
From: Christophe R. <cs...@ca...> - 2010-01-24 19:39:00
|
Harald Hanche-Olsen <ha...@ma...> writes: > Building sbcl failed yesterday: > > WARNING! Some of the contrib modules did not build successfully or pass > their self-tests. Failed contribs:" [lots] > This is on Intel Mac OS X 10.5.8, building with sbcl 1.0.33.30. >From memory, there were some OS X related changes in the 1.0.34 series... could you see if reverting any of them removes the problem? Thanks, Christophe |
From: Harald Hanche-O. <ha...@ma...> - 2010-01-24 21:41:25
|
+ Harald Hanche-Olsen <ha...@ma...>: > The results of > (sb-unix:unix-stat "/local/src/lisp/sbcl/sbcl-git/clean.sh") > which the bad sbcl thinks is a directory Sorry, I was a bit cryptic there. I had a draft message to the list that I thought that I had sent, but hadn't, and which pointed to this behaviour in 1.0.34.9: * (probe-file "/local/src/lisp/sbcl/sbcl-git/clean.sh") #P"/local/src/lisp/sbcl/sbcl-git/clean.sh/" which is presumably explained by the unix-stat bug that I showed. - Harald |
From: Harald Hanche-O. <ha...@ma...> - 2010-01-25 13:54:32
|
+ Kei Suzuki <ks...@gm...>: > 1. Run 'uname -r' on the command line. What number is back? 9.8.0 > 2. Git pull for 1.0.34.9 and run 'sh make.sh >build.log'. No need, I always keep a log of my sbcl builds. > Then open build.log and find the sbcl_arch line. What does it say, > sbcl_arch="x86" or sbcl_arch="x86-64"? sbcl_arch="x86-64" > 3. Couple of lines below from the sbcl_arch line you should see the > lines listing *shebang-features* like this: > > * target features *SHEBANG-FEATURES*=(:ANSI-CL :COMMON-LISP :SBCL :SB-DOC > :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS > :SB-UNICODE :SB-EVAL > :SB-SOURCE-LOCATIONS > :IEEE-FLOATING-POINT :X86-64 :INODE64 > > Do you see :INODE64 in your *shebang-features*? Yes. > 4. In build.log find the line: > > * //entering make-target-1.sh > > There should be bunch of cc lines below the line, like this: > > cc -g -Wall -O2 -fdollars-in-identifiers -mmacosx-version-min=10.5 > -D_DARWIN_USE_64_BIT_INODE -arch x86_64 -fno-omit-frame-pointer > -pagezero_size 0x100000 -I. -c -o alloc.o alloc.c > > What does your cc line for alloc.c look like? cc -g -Wall -O2 -fdollars-in-identifiers -mmacosx-version-min=10.5 -D_DARWIN_USE_64_BIT_INODE -arch x86_64 -fno-omit-frame-pointer -pagezero_size 0x100000 -I. -c -o alloc.o alloc.c > 5. Open output/stuff-groveled-from-headers.lisp and find the > define-alien-type line for ino-t. Does the line look like this? > > (define-alien-type ino-t (unsigned 64)) No, it looks like (define-alien-type ino-t (unsigned 32)) Oops. That can't be good, can it? > 6. Open /usr/include/sys/cdefs.h and look for the first ifdef line for > __DARWIN_64_BIT_INO_T. Do the first and following lines look like > these? > > #if !defined(__DARWIN_64_BIT_INO_T) > # if defined(_DARWIN_USE_64_BIT_INODE) > # define __DARWIN_64_BIT_INO_T 1 > # elif defined(_DARWIN_NO_64_BIT_INODE) || defined(KERNEL) > # define __DARWIN_64_BIT_INO_T 0 > # else /* default */ > # define __DARWIN_64_BIT_INO_T 0 > # endif > #endif /* !__DARWIN_64_BIT_INO_T */ Yep. > 7. Run this command > > export SBCL_ARCH=x86 > > and run 'sh make.sh' again. Does it succeed then? I'll report back shortly. It's building while I have a cup of coffee. - Harald |
From: Harald Hanche-O. <ha...@ma...> - 2010-01-25 14:05:03
|
+ Harald Hanche-Olsen <ha...@ma...>: > > 7. Run this command > > > > export SBCL_ARCH=x86 > > > > and run 'sh make.sh' again. Does it succeed then? Coffee break is over. The answer is no: //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.34.9, 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. Argh! error in cold init, halting fatal error encountered in SBCL pid 82313: %PRIMITIVE HALT called; the party is over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Ouch. - Harald |
From: Harald Hanche-O. <ha...@ma...> - 2010-01-25 14:20:00
|
+ Harald Hanche-Olsen <ha...@ma...>: > > 5. Open output/stuff-groveled-from-headers.lisp and find the > > define-alien-type line for ino-t. Does the line look like this? > > > > (define-alien-type ino-t (unsigned 64)) > > No, it looks like > > (define-alien-type ino-t (unsigned 32)) > > Oops. That can't be good, can it? I don't understand all this grovel stuff, but if you can provide me with a few hints and pointers as to how it works, I can try to trace this one and see if I can figure out why it happens. - Harald |
From: Harald Hanche-O. <ha...@ma...> - 2010-01-24 20:09:47
|
+ Christophe Rhodes <cs...@ca...>: > Harald Hanche-Olsen <ha...@ma...> writes: > > > Building sbcl failed yesterday: > > > > WARNING! Some of the contrib modules did not build successfully or pass > > their self-tests. Failed contribs:" > [lots] > > > This is on Intel Mac OS X 10.5.8, building with sbcl 1.0.33.30. > > From memory, there were some OS X related changes in the 1.0.34 > series... could you see if reverting any of them removes the problem? Well, at least, rolling back just one commit to 1.0.34.8 (git commit 09e08ad0ba4eb09cd1a08ef5b7da527757ca78e5) cured it. I'll see if I can narrow it down further. (Real life keeps intruding ...) - Harald |
From: Harald Hanche-O. <ha...@ma...> - 2010-01-24 21:33:56
|
+ Harald Hanche-Olsen <ha...@ma...>: > Well, at least, rolling back just one commit to 1.0.34.8 (git commit > 09e08ad0ba4eb09cd1a08ef5b7da527757ca78e5) cured it. I'll see if I can > narrow it down further. (Real life keeps intruding ...) I poked around in the source a bit, and so it occured to me to try out sb-unix:unix-stat in a good sbcl and a bad one. The results of (sb-unix:unix-stat "/local/src/lisp/sbcl/sbcl-git/clean.sh") which the bad sbcl thinks is a directory are as follows: 1.0.33.30 1.0.34.9 T T 234881026 234881026 936912 0 <--- inode number 33261 19408 <--- mode 1 14 13799 0 80 98797 0 13799 4147 80 1255394773 16 1237026090 1255394773 1245258805 1237026090 4096 4147 16 4096 The discrepancies are legion, most notably the mode, here translated into octal: 100755 45720 The one on the left makes sense, the one on the right does not. It seems to me that the changes in 1.0.34.9 are too iffy to be part of 1.0.34, unless someone can come up with a good explanation and fix. Rollback time? - Harald |
From: Kei S. <ks...@gm...> - 2010-01-25 07:40:39
|
Hi Mr. Hanche-Olsen, 1.0.34.9 builds successfully on my Intel Mac OS 10.6.2 (I used sbcl 1.0.29 to build). I want to understand what's going on your machine. Could you check the followings? 1. Run 'uname -r' on the command line. What number is back? 2. Git pull for 1.0.34.9 and run 'sh make.sh >build.log'. Then open build.log and find the sbcl_arch line. What does it say, sbcl_arch="x86" or sbcl_arch="x86-64"? 3. Couple of lines below from the sbcl_arch line you should see the lines listing *shebang-features* like this: * target features *SHEBANG-FEATURES*=(:ANSI-CL :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86-64 :INODE64 Do you see :INODE64 in your *shebang-features*? 4. In build.log find the line: * //entering make-target-1.sh There should be bunch of cc lines below the line, like this: cc -g -Wall -O2 -fdollars-in-identifiers -mmacosx-version-min=10.5 -D_DARWIN_USE_64_BIT_INODE -arch x86_64 -fno-omit-frame-pointer -pagezero_size 0x100000 -I. -c -o alloc.o alloc.c What does your cc line for alloc.c look like? 5. Open output/stuff-groveled-from-headers.lisp and find the define-alien-type line for ino-t. Does the line look like this? (define-alien-type ino-t (unsigned 64)) 6. Open /usr/include/sys/cdefs.h and look for the first ifdef line for __DARWIN_64_BIT_INO_T. Do the first and following lines look like these? #if !defined(__DARWIN_64_BIT_INO_T) # if defined(_DARWIN_USE_64_BIT_INODE) # define __DARWIN_64_BIT_INO_T 1 # elif defined(_DARWIN_NO_64_BIT_INODE) || defined(KERNEL) # define __DARWIN_64_BIT_INO_T 0 # else /* default */ # define __DARWIN_64_BIT_INO_T 0 # endif #endif /* !__DARWIN_64_BIT_INO_T */ 7. Run this command export SBCL_ARCH=x86 and run 'sh make.sh' again. Does it succeed then? If your answers were all the same as I expect, then the patch applied to 1.0.34.9 works for 10.6 but is still missing something for 10.5 so that it should be backed out, unfortunately. On Mon, Jan 25, 2010 at 6:41 AM, Harald Hanche-Olsen <ha...@ma...> wrote: > + Harald Hanche-Olsen <ha...@ma...>: > >> The results of >> (sb-unix:unix-stat "/local/src/lisp/sbcl/sbcl-git/clean.sh") >> which the bad sbcl thinks is a directory > > Sorry, I was a bit cryptic there. I had a draft message to the list > that I thought that I had sent, but hadn't, and which pointed to this > behaviour in 1.0.34.9: > > * (probe-file "/local/src/lisp/sbcl/sbcl-git/clean.sh") > > #P"/local/src/lisp/sbcl/sbcl-git/clean.sh/" > > which is presumably explained by the unix-stat bug that I showed. > > - Harald > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > -- Kei Suzuki |
From: Christophe R. <cs...@ca...> - 2010-01-25 14:05:59
|
Harald Hanche-Olsen <ha...@ma...> writes: >> 5. Open output/stuff-groveled-from-headers.lisp and find the >> define-alien-type line for ino-t. Does the line look like this? >> >> (define-alien-type ino-t (unsigned 64)) > > No, it looks like > > (define-alien-type ino-t (unsigned 32)) > > Oops. That can't be good, can it? The binary grovel-headers doesn't get automatically recompiled on a change of features -- in particular, on a change of SBCL_ARCH. Does removing it by hand and doing a full recompile help? If that binary dates from before Darwin defaulted to x86-64... Cheers, Christophe |
From: Kei S. <ks...@gm...> - 2010-01-26 01:23:34
|
Mr. Hanche-Olsen, Thank you for your answers. Everything looks as expected except (define-alien-type ino-t (unsigned 32)), of which type size should be (unsigned 64), and that puzzles me. On Mon, Jan 25, 2010 at 11:55 PM, Harald Hanche-Olsen <ha...@ma...> wrote: > + Christophe Rhodes <cs...@ca...>: > >> The binary grovel-headers doesn't get automatically recompiled on a >> change of features -- in particular, on a change of SBCL_ARCH. Does >> removing it by hand and doing a full recompile help? If that binary >> dates from before Darwin defaulted to x86-64... > > Yeah, that fixed it. I just want to reconfirm: did removing the stale file make your build succeed with and without the SBCL_ARCH setting so that I don't need to pursue this issue any more? Whenever I make a build with significant changes (e.g. after git pull/checkout, setting SBCL_ARCH), I always run clean.sh before make.sh in order to ensure a clean build. In case if you are wondering what the heck the 1.0.34.9 patch is for, my original post may help you understand more: http://groups.google.com/group/sbcl-devel/browse_thread/thread/8f9f5e004a80a00d# > > However, I don't think your explanation quite right, for I have been > compiling for x86-64 since September, and grovel-headers did get > automatically recompiled in December. > > - Harald > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > -- Kei Suzuki |
From: Harald Hanche-O. <ha...@ma...> - 2010-01-26 03:10:36
|
+ Kei Suzuki <ks...@gm...>: > On Mon, Jan 25, 2010 at 11:55 PM, Harald Hanche-Olsen > <ha...@ma...> wrote: > > + Christophe Rhodes <cs...@ca...>: > > > >> The binary grovel-headers doesn't get automatically recompiled on a > >> change of features -- in particular, on a change of SBCL_ARCH. Does > >> removing it by hand and doing a full recompile help? If that binary > >> dates from before Darwin defaulted to x86-64... > > > > Yeah, that fixed it. > > I just want to reconfirm: did removing the stale file make your build > succeed with and without the SBCL_ARCH setting so that I don't need to > pursue this issue any more? I hadn't retested it with SBCL_ARCH=x86, but I tried it just now (after running clean.sh), and I can say that with or without it, removing grovel-headers made the build succeed. I don't think you need to worry about this anymore. > Whenever I make a build with significant changes (e.g. after git > pull/checkout, setting SBCL_ARCH), I always run clean.sh before > make.sh in order to ensure a clean build. Okay. But if that is recommended practice, then I think the INSTALL file should mention it. It does not. (I had noticed the file, but thought maybe it would be executed as part of a normal build.) - Harald |
From: Kei S. <ks...@gm...> - 2010-01-26 03:35:23
|
On Tue, Jan 26, 2010 at 12:10 PM, Harald Hanche-Olsen <ha...@ma...> wrote: > + Kei Suzuki <ks...@gm...>: > >> On Mon, Jan 25, 2010 at 11:55 PM, Harald Hanche-Olsen >> <ha...@ma...> wrote: >> > + Christophe Rhodes <cs...@ca...>: >> > >> >> The binary grovel-headers doesn't get automatically recompiled on a >> >> change of features -- in particular, on a change of SBCL_ARCH. Does >> >> removing it by hand and doing a full recompile help? If that binary >> >> dates from before Darwin defaulted to x86-64... >> > >> > Yeah, that fixed it. >> >> I just want to reconfirm: did removing the stale file make your build >> succeed with and without the SBCL_ARCH setting so that I don't need to >> pursue this issue any more? > > I hadn't retested it with SBCL_ARCH=x86, but I tried it just now > (after running clean.sh), and I can say that with or without it, > removing grovel-headers made the build succeed. I don't think you need > to worry about this anymore. Great. Thanks! -- Kei Suzuki |
From: Harald Hanche-O. <ha...@ma...> - 2010-01-25 14:56:03
|
+ Christophe Rhodes <cs...@ca...>: > The binary grovel-headers doesn't get automatically recompiled on a > change of features -- in particular, on a change of SBCL_ARCH. Does > removing it by hand and doing a full recompile help? If that binary > dates from before Darwin defaulted to x86-64... Yeah, that fixed it. However, I don't think your explanation quite right, for I have been compiling for x86-64 since September, and grovel-headers did get automatically recompiled in December. - Harald |
From: Cyrus H. <ch...@bo...> - 2010-01-25 07:58:00
|
Just out of curiosity, did you try rebuilding 1.0.34.9 with itself and see if that fixed the problem? I'm wondering if there isn't some cross-compile problem with 1.0.34.9 built with a pre-1.0.34.9 build. thanks, Cyrus On Jan 24, 2010, at 1:33 PM, Harald Hanche-Olsen wrote: > + Harald Hanche-Olsen <ha...@ma...>: > >> Well, at least, rolling back just one commit to 1.0.34.8 (git commit >> 09e08ad0ba4eb09cd1a08ef5b7da527757ca78e5) cured it. I'll see if I can >> narrow it down further. (Real life keeps intruding ...) > > I poked around in the source a bit, and so it occured to me to try out > sb-unix:unix-stat in a good sbcl and a bad one. The results of > (sb-unix:unix-stat "/local/src/lisp/sbcl/sbcl-git/clean.sh") > which the bad sbcl thinks is a directory are as follows: > > 1.0.33.30 1.0.34.9 > T T > 234881026 234881026 > 936912 0 <--- inode number > 33261 19408 <--- mode > 1 14 > 13799 0 > 80 98797 > 0 13799 > 4147 80 > 1255394773 16 > 1237026090 1255394773 > 1245258805 1237026090 > 4096 4147 > 16 4096 > > The discrepancies are legion, most notably the mode, here translated > into octal: > > 100755 45720 > > The one on the left makes sense, the one on the right does not. > > It seems to me that the changes in 1.0.34.9 are too iffy to be part of > 1.0.34, unless someone can come up with a good explanation and fix. > Rollback time? > > - Harald > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Kei S. <ks...@gm...> - 2010-01-25 09:42:14
|
Hi Cyrus, Building 1.0.34.9 with itself is fine. What OS X version are you using to build 1.0.34.9? Do you have 10.5 and see the same failures? On Mon, Jan 25, 2010 at 4:57 PM, Cyrus Harmon <ch...@bo...> wrote: > Just out of curiosity, did you try rebuilding 1.0.34.9 with itself and see if that fixed the problem? I'm wondering if there isn't some cross-compile problem with 1.0.34.9 built with a pre-1.0.34.9 build. > > thanks, > > Cyrus > > On Jan 24, 2010, at 1:33 PM, Harald Hanche-Olsen wrote: > >> + Harald Hanche-Olsen <ha...@ma...>: >> >>> Well, at least, rolling back just one commit to 1.0.34.8 (git commit >>> 09e08ad0ba4eb09cd1a08ef5b7da527757ca78e5) cured it. I'll see if I can >>> narrow it down further. (Real life keeps intruding ...) >> >> I poked around in the source a bit, and so it occured to me to try out >> sb-unix:unix-stat in a good sbcl and a bad one. The results of >> (sb-unix:unix-stat "/local/src/lisp/sbcl/sbcl-git/clean.sh") >> which the bad sbcl thinks is a directory are as follows: >> >> 1.0.33.30 1.0.34.9 >> T T >> 234881026 234881026 >> 936912 0 <--- inode number >> 33261 19408 <--- mode >> 1 14 >> 13799 0 >> 80 98797 >> 0 13799 >> 4147 80 >> 1255394773 16 >> 1237026090 1255394773 >> 1245258805 1237026090 >> 4096 4147 >> 16 4096 >> >> The discrepancies are legion, most notably the mode, here translated >> into octal: >> >> 100755 45720 >> >> The one on the left makes sense, the one on the right does not. >> >> It seems to me that the changes in 1.0.34.9 are too iffy to be part of >> 1.0.34, unless someone can come up with a good explanation and fix. >> Rollback time? >> >> - Harald >> >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for Conference >> attendees to learn about information security's most important issues through >> interactions with peers, luminaries and emerging and established companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> Sbcl-devel mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > -- Kei Suzuki |
From: Cyrus H. <ch...@bo...> - 2010-01-25 16:28:04
|
Actually, it was more building 1.0.34.9 with an older version that worried me. I saw a similar (the same?) error once, but was unable to reproduce it (all on 10.6.2). cyrus On Jan 25, 2010, at 1:42 AM, Kei Suzuki wrote: > Hi Cyrus, > > Building 1.0.34.9 with itself is fine. > > What OS X version are you using to build 1.0.34.9? Do you have 10.5 > and see the same failures? > > On Mon, Jan 25, 2010 at 4:57 PM, Cyrus Harmon <ch...@bo...> wrote: >> Just out of curiosity, did you try rebuilding 1.0.34.9 with itself and see if that fixed the problem? I'm wondering if there isn't some cross-compile problem with 1.0.34.9 built with a pre-1.0.34.9 build. >> >> thanks, >> >> Cyrus >> >> On Jan 24, 2010, at 1:33 PM, Harald Hanche-Olsen wrote: >> >>> + Harald Hanche-Olsen <ha...@ma...>: >>> >>>> Well, at least, rolling back just one commit to 1.0.34.8 (git commit >>>> 09e08ad0ba4eb09cd1a08ef5b7da527757ca78e5) cured it. I'll see if I can >>>> narrow it down further. (Real life keeps intruding ...) >>> >>> I poked around in the source a bit, and so it occured to me to try out >>> sb-unix:unix-stat in a good sbcl and a bad one. The results of >>> (sb-unix:unix-stat "/local/src/lisp/sbcl/sbcl-git/clean.sh") >>> which the bad sbcl thinks is a directory are as follows: >>> >>> 1.0.33.30 1.0.34.9 >>> T T >>> 234881026 234881026 >>> 936912 0 <--- inode number >>> 33261 19408 <--- mode >>> 1 14 >>> 13799 0 >>> 80 98797 >>> 0 13799 >>> 4147 80 >>> 1255394773 16 >>> 1237026090 1255394773 >>> 1245258805 1237026090 >>> 4096 4147 >>> 16 4096 >>> >>> The discrepancies are legion, most notably the mode, here translated >>> into octal: >>> >>> 100755 45720 >>> >>> The one on the left makes sense, the one on the right does not. >>> >>> It seems to me that the changes in 1.0.34.9 are too iffy to be part of >>> 1.0.34, unless someone can come up with a good explanation and fix. >>> Rollback time? >>> >>> - Harald >>> >>> ------------------------------------------------------------------------------ >>> Throughout its 18-year history, RSA Conference consistently attracts the >>> world's best and brightest in the field, creating opportunities for Conference >>> attendees to learn about information security's most important issues through >>> interactions with peers, luminaries and emerging and established companies. >>> http://p.sf.net/sfu/rsaconf-dev2dev >>> _______________________________________________ >>> Sbcl-devel mailing list >>> Sbc...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbcl-devel >> >> >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for Conference >> attendees to learn about information security's most important issues through >> interactions with peers, luminaries and emerging and established companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> Sbcl-devel mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel >> > > > > -- > Kei Suzuki > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Cyrus H. <ch...@bo...> - 2010-01-25 22:30:27
|
Yes, as you have pointed out, it's much more likely that the culprit is the grovel-headers thing. Should this be more aggressively recompiled? thanks, Cyrus On Jan 25, 2010, at 8:47 AM, Christophe Rhodes wrote: > Cyrus Harmon <ch...@bo...> writes: > >> Actually, it was more building 1.0.34.9 with an older version that >> worried me. I saw a similar (the same?) error once, but was unable to >> reproduce it (all on 10.6.2). > > I'm sorry, but I simply do not believe that there can be any difference > due to the host compiler that is in any way significant, absent any > evidence to the contrary. I did a significant amount of work to make > the fasl files produced by the cross-compiler bit-for-bit identical > between sbcl and clisp... that may have leaked or been unfinished, but > come on. > > I would blame cosmic rays or lack of ECC RAM before host compiler > leakage into compiling _contribs_. > > Christophe |
From: Harald Hanche-O. <ha...@ma...> - 2010-01-26 03:28:44
|
+ Cyrus Harmon <ch...@bo...>: > Yes, as you have pointed out, it's much more likely that the culprit > is the grovel-headers thing. To me it seems like a dead certainty. > Should this be more aggressively recompiled? I think it's a good idea. How long can it take anyhow, compared to the rest of the build process? [Answer: 1 second on my machine.] I say rebuild it every time. - Harald |
From: Christophe R. <cs...@ca...> - 2010-01-25 16:47:49
|
Cyrus Harmon <ch...@bo...> writes: > Actually, it was more building 1.0.34.9 with an older version that > worried me. I saw a similar (the same?) error once, but was unable to > reproduce it (all on 10.6.2). I'm sorry, but I simply do not believe that there can be any difference due to the host compiler that is in any way significant, absent any evidence to the contrary. I did a significant amount of work to make the fasl files produced by the cross-compiler bit-for-bit identical between sbcl and clisp... that may have leaked or been unfinished, but come on. I would blame cosmic rays or lack of ECC RAM before host compiler leakage into compiling _contribs_. Christophe |