From: Tarjei V. <tar...@ny...> - 2003-11-01 15:44:38
|
Hello! I decided to try the -devel list; please let me know if this is a "-help"-question instead.=20 I'm trying so compile SBCL from the 0.8.5-sources on my OpenBSD 3.4/i386 box. GCC is 2.95.3, GNU make 3.80. I'd thought I'd bootstrap it with clisp. However, it fails when building the runtime system, with these errors: cc -g -Wall -O3 -I. -c -o alloc.o alloc.c In file included from os.h:40, from alloc.c:22: target-os.h:21: syntax error before `os_vm_size_t' target-os.h:21: warning: type defaults to `int' in declaration of `os_vm_= size_t' target-os.h:21: warning: data definition has no type or storage class In file included from alloc.c:22: os.h:46: syntax error before `os_vm_page_size' os.h:46: warning: type defaults to `int' in declaration of `os_vm_page_si= ze' os.h:46: warning: data definition has no type or storage class os.h:66: syntax error before `os_vm_size_t' os.h:73: syntax error before `os_vm_size_t' os.h:76: syntax error before `os_vm_size_t' os.h:83: syntax error before `os_vm_size_t' os.h:89: syntax error before `os_vm_size_t' os.h:95: syntax error before `os_vm_size_t' os.h:147: syntax error before `len' os.h:148: syntax error before `os_vm_size_t' os.h:150: syntax error before `os_vm_size_t' os.h:152: syntax error before `os_vm_size_t' In file included from alloc.c:26: gc.h:27: syntax error before `usage' alloc.c: In function `pa_alloc': alloc.c:57: warning: implicit declaration of function `do_pending_interru= pt' gmake: *** [alloc.o] Error 1 ------ I try to change target-os.h:21 from typedef vm_size_t os_vm_size_t; to typedef size_t os_vm_size_t; as suggested by Hannah Schroeter. Now, the build fails on bsd-os.c: cc -g -Wall -O3 -I. -c -o bsd-os.o bsd-os.c bsd-os.c:40: syntax error before `os_vm_page_size' bsd-os.c:40: warning: type defaults to `int' in declaration of `os_vm_pag= e_size' bsd-os.c:40: conflicting types for `os_vm_page_size' os.h:46: previous declaration of `os_vm_page_size' bsd-os.c:40: warning: data definition has no type or storage class bsd-os.c: In function `is_valid_lisp_addr': bsd-os.c:142: warning: comparison of distinct pointer types lacks a cast bsd-os.c:142: warning: comparison of distinct pointer types lacks a cast bsd-os.c:144: warning: passing arg 2 of `in_range_p' makes integer from p= ointer without a cast bsd-os.c: In function `memory_fault_handler': bsd-os.c:175: warning: implicit declaration of function `gencgc_handle_wp= _violation' gmake: *** [bsd-os.o] Error 1 ----- I suppose this doesn't help very much. What information should I provide to help diagnose the problem? Thanks in advance,=20 Tarjei V=E5gst=F8l |
From: William H. N. <wil...@ai...> - 2003-11-02 04:24:22
|
On Sat, Nov 01, 2003 at 04:35:56PM +0100, Tarjei Vagstol wrote: > I decided to try the -devel list; please let me know if this is a > "-help"-question instead. Since I'm going to suggest below that you try to create a patch yourself, -devel may be more appropriate than you expected.:-) Seriously, "can you help me with this apparent bug" fits so well on either list that it's probably not worth trying to classify it. > I'm trying so compile SBCL from the 0.8.5-sources on my OpenBSD > 3.4/i386 box. GCC is 2.95.3, GNU make 3.80. I'd thought I'd bootstrap > it with clisp. (It's almost certainly not relevant to the current problem, but if you encounter other problems later, note that the clisp version may be important. I haven't thought about it for a while, and I certainly don't remember which versions were involved, but I dimly remember that building SBCL pushes various limitations (pretty-printer, garbage collector...) of various versions of clisp past the breaking point.) > However, it fails when building the runtime system, with these errors: > > cc -g -Wall -O3 -I. -c -o alloc.o alloc.c > In file included from os.h:40, > from alloc.c:22: > target-os.h:21: syntax error before `os_vm_size_t' > target-os.h:21: warning: type defaults to `int' in declaration of `os_vm_size_t' > target-os.h:21: warning: data definition has no type or storage class [snip] > I try to change target-os.h:21 from > typedef vm_size_t os_vm_size_t; > to > typedef size_t os_vm_size_t; > > as suggested by Hannah Schroeter. Now, the build fails on bsd-os.c: Note that target-os.h is supposed to be a symbolic link to the underlying file (bsd-os.h for OpenBSD, I think). Thus, when you edit target-os.h and write out a new version, it's not intuitively obvious what the editor's correct action should be; but that may not stop the editor from silently trying to DWIM by e.g. overwriting the symlink with a modified copy of the file (but leaving the original bsd-os.h unchanged). If that scenario is as confusing to you as it is to me, you might want to start anew with a clean copy of the sources, edit bsd-os.h directly, and then restart the build from scratch (which should regenerate the target-os.h symlink from scratch). > cc -g -Wall -O3 -I. -c -o bsd-os.o bsd-os.c > bsd-os.c:40: syntax error before `os_vm_page_size' > bsd-os.c:40: warning: type defaults to `int' in declaration of `os_vm_page_size' > bsd-os.c:40: conflicting types for `os_vm_page_size' [snip] > I suppose this doesn't help very much. What information should I > provide to help diagnose the problem? No, this actually looks like a pretty good bug report. If I still had an OpenBSD machine I would probably bestir myself to try to fix the problem. But then, if I still had an OpenBSD machine the port might not have rotted this much in the first place. It looks like the system just wants to know what vm_size_t should be for OpenBSD, and trying to replace it with size_t sounds plausible. And even if that's not the fix, the fix is likely to be very simple, a line or two of code along the lines of the #ifdef __FreeBSD__ #include <osreldate.h> #endif or #if defined __OpenBSD__ typedef struct sigaltstack stack_t; hackery that you can see at the head of bsd-os.h. But even if I were highly motivated to try to debug and fix the problem myself, it could be hard to do so without an OpenBSD machine to do it on. If you do find a solution, we'd probably be happy to merge a patch. -- William Harold Newman <wil...@ai...> We were bedevilled by the daemons of diagrammatic overdesign. My God, three little boxes drawn on the back of a napkin, Game, Frame, and Throw, and it was still too complicated and just plain wrong. -- Robert C. Martin, _Agile Software Development_, p. 72 PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Tarjei V. <tar...@ny...> - 2003-11-02 20:55:47
|
* William Harold Newman > If you do find a solution, we'd probably be happy to merge a patch. I'm still working on the problem, but let me state clearly that I'm way out of my league here (thus, I'll not be surprised if you end up suggesting I install FreeBSD ;-)). I believe my clisp version was a problem. The version installed from the OpenBSD ports tree was 2.27; I've now installed 2.31 by hand. I believe finally managed to build the SBCL runtime system. I say "believe", because build now fails at a later stage. Anyway, this is what I did. 1. bsd-os.h changed "typedef vm_size_t os_vm_size_t;" to "typedef size_t os_vm_size_t;" bsd-os.c changed "vm_size_t os_vm_page_size;" to "size_t os_vm_page_size;" 2. OpenBSD no longer seems to use underscore in front of function names; I changed the file x86-assem.S to reflect this: /* Minimize conditionalization for different OS naming schemes. */ #if defined __linux__ || defined __FreeBSD__ || defined __OpenBSD__ /* (but *not* OpenBSD) */ #define GNAME(var) var #else #define GNAME(var) _##var #endif 3. LISP_FEATURE_LINUX seemed to be defined somewhere. This caused the linking to fail, so I commented out all blocks containing "#ifdef LISP_FEATURE_LINUX". (also in the file tools-for-build/grovel_headers.c). [I know, this is ugly] 4. #ifndef SVR4 F(swapon) #endif in the file "undefineds.h" caused link failure, so I commented it out, too. The runtime system seems to get properly build now. Gmake in the src/runtime dir ends with: cc -g -static -o sbcl alloc.o backtrace.o breakpoint.o coreparse.o dynbind.o gc-common.o globals.o interr.o interrupt.o monitor.o parse.o print.o purify.o regnames.o run-program.o runtime.o save.o search.o thread.o time.o util.o validate.o vars.o wrap.o x86-arch.o x86-assem.o bsd-os.o os-common.o undefineds.o x86-bsd-os.o gencgc.o -lm -lm runtime.o: In function `main': /home/tarjei/src/sbcl/src/runtime/runtime.c:293: warning: sprintf() is often misused, please use snprintf() nm -gp sbcl | grep -v " F \| U " > ,sbcl.nm mv -f ,sbcl.nm sbcl.nm but the SBCL build process fails after a while: [...] *** - READ: input stream #<INPUT BUFFERED FILE-STREAM CHARACTER #P"output/object-filenames-for-genesis.lisp-expr" @1> has reached its end ;; Loading file obj/from-host/src/compiler/generic/genesis.lisp-obj ... WARNING: DEFUN/DEFMACRO: redefining function FOP-MAYBE-COLD-LOAD in /home/tarjei/src/sbcl/obj/from-host/src/compiler/generic/genesis.lisp-obj, was defined in /home/tarjei/src/sbcl/obj/from-host/src/code/fop.lisp-obj ;; Loaded file obj/from-host/src/compiler/generic/genesis.lisp-obj T *** - EVAL: variable *TARGET-OBJECT-FILE-NAMES* has no value Bye. //testing for consistency of first and second GENESIS passes diff: output/genesis-2: No such file or directory error: header files do not match between first and second GENESIS $ Can this be because I broke the runtime system, even if it seemed to compile and link? Can I verify the soundness of the runtime system somehow? Thanks, Tarjei |
From: William H. N. <wil...@ai...> - 2003-11-03 18:19:55
|
On Sun, Nov 02, 2003 at 09:55:28PM +0100, Tarjei Vagstol wrote: > * William Harold Newman > > If you do find a solution, we'd probably be happy to merge a patch. > > I'm still working on the problem, but let me state clearly that I'm > way out of my league here (thus, I'll not be surprised if you end up > suggesting I install FreeBSD ;-)). > > I believe my clisp version was a problem. The version installed from the > OpenBSD ports tree was 2.27; I've now installed 2.31 by hand. I don't know the relevant CLISP version numbers, so I don't know whether this is good enough or not, but it does sound likelier to be good. It's noteworthy bad luck that the world expert on bootstrapping SBCL under CLISP departed for some dark part of France about 24 hours ago, warning that wherever he'll be for six weeks (Paris?) it's unlike the light parts (Bordeaux, e.g.) in that he'll have only very intermittent Internet connectivity. [snipped: various tweaks in runtime that look plausible] > The runtime system seems to get properly build now. Gmake in the src/runtime > dir ends with: > > cc -g -static -o sbcl alloc.o backtrace.o breakpoint.o coreparse.o dynbind.o gc-common.o globals.o interr.o interrupt.o monitor.o parse.o print.o purify.o regnames.o run-program.o runtime.o save.o search.o thread.o time.o util.o validate.o vars.o wrap.o x86-arch.o x86-assem.o bsd-os.o os-common.o undefineds.o x86-bsd-os.o gencgc.o -lm -lm > runtime.o: In function `main': > /home/tarjei/src/sbcl/src/runtime/runtime.c:293: warning: sprintf() is often misused, please use snprintf() > nm -gp sbcl | grep -v " F \| U " > ,sbcl.nm > mv -f ,sbcl.nm sbcl.nm Good. > but the SBCL build process fails after a while: > > [...] > *** - READ: input stream > #<INPUT BUFFERED FILE-STREAM CHARACTER > #P"output/object-filenames-for-genesis.lisp-expr" @1> has reached its end > ;; Loading file obj/from-host/src/compiler/generic/genesis.lisp-obj ... > WARNING: > DEFUN/DEFMACRO: redefining function FOP-MAYBE-COLD-LOAD in /home/tarjei/src/sbcl/obj/from-host/src/compiler/generic/genesis.lisp-obj, was defined in /home/tarjei/src/sbcl/obj/from-host/src/code/fop.lisp-obj > ;; Loaded file obj/from-host/src/compiler/generic/genesis.lisp-obj > T > *** - EVAL: variable *TARGET-OBJECT-FILE-NAMES* has no value That should be coming from the commands that are executing in make-genesis-2.sh. The relevant lines in that file are (defparameter *target-object-file-names* (with-open-file (s "output/object-filenames-for-genesis.lisp-expr" :direction :input) (read s))) (host-load-stem "src/compiler/generic/genesis") Thus, *TARGET-OBJECT-FILE-NAMES* is intended to be bound at the time that genesis gets loaded. Could you look a little further back in the error output to see if there's a complete error message from when the DEFPARAMETER is executed? What you included in your message, *** - READ: input stream #<INPUT BUFFERED FILE-STREAM CHARACTER #P"output/object-filenames-for-genesis.lisp-expr" @1> has reached its end looks like the tail end of a complaint showing that CLISP was not reading successfully, but I'm insufficiently familiar with CLISP's error reporting and typical build-under-CLISP issues to leap from that to what the problem is. It might also be helpful if you could look at output/object-filenames-for-genesis.lisp-expr yourself, and if it's in some state which is easy to summarize (like "it's empty" or "it doesn't exist" or "it contains the following 21 lines...") report that here. As suggested by the name of the directory that that file lives in, that file is output from earlier in the build process. Quite possibly it is in a confused state because of some error which occurred earlier. Incidentally, you may be thinking at this point that it would be less gruesomely bad software engineering if the build would *just* *stop* *immediately* when an error occurred (like failing to read output/object-filenames-for-genesis.lisp-expr), instead of staggering along for a while, getting more and more confused, before expiring. I agree. In defense of the good sense of the SBCL crew, I believe that's what the system would have done if it was building under the usual cross-compilation hosts, where the build uses commands like "sbcl --disable-debugger" so that the first fatal error terminates the run immediately. Thus, this "only a flesh wound" silliness is a problem only in unusual cases (like, unfortunately for you, building under CLISP), and thus, there's no great incentive for us to maintain hacks like (defparameter *target-object-file-names* (or (ignore-errors (with-open-file (s "output/object-filenames-for-genesis.lisp-expr" :direction :input) (read s)) (progn #+clisp (clisp-extensions:abort-or-whatever-it-is) #+cmu (ext:quit) #+sbcl (sb-ext:quit) (error "Damn! Don't know how to QUIT... Oh, well."))))) (or (ignore-errors (host-load-stem "src/compiler/generic/genesis")) (progn #+clisp ...)) (where by ignoring OAOO I've exaggerated the problem for comic effect). In the kind of build that most people do most of the time, this troubleshooting would probably be less aggravatingly dependent on corresponding by email with someone who can guess where to look back in tens of thousands of lines of build output. > Can this be because I broke the runtime system, even if it seemed to > compile and link? Can I verify the soundness of the runtime system > somehow? I doubt it. The stuff which was compiled in src/runtime/ shouldn't be being actively used at that point. (A few numeric values from src/runtime/ should have been used, but the compiled code isn't being executed or anything. The main reason that the runtime had to be built earlier, before the cross-compiler ran, is that the cross-compiler needs to know the static locations of functions that it compiles calls to. Now those calls have been compiled, but still never executed.) It's still possible that the root cause of the current failure could be in src/runtime/ stuff, but if so it's probably not subtle logical corruption. The kind of remaining src/runtime/ problem I'd anticipate would be e.g. OpenBSD maintainers tweaking the command line options or output format of some tool like nm, so that the hackery we use to produce linkage table information has stopped working, giving us garbage or no data at all where we expect to find a table of addresses. I don't think there's any ironclad way to verify the soundness of the src/runtime/ stuff. What I'd do: * Check key completion messages. This is just stuff like the completion without errors of the "cc" command you showed above, so you're basically already doing this. * Verify that you haven't inadvertently changed anything, or lost track of one of your changes, by using an automated diff to report your changes. The way we usually do it is checking a copy of the tree out of CVS, fiddling with the local copy, then running "cvs diff -u" to summarize changes. Depending on how cranky sourceforge anoncvs is for you, that may not be an option, in which case you can hack up something similar with a clean copy of the sources in one directory, your working copy in another directory, and "diff -R". > Thanks, You're welcome. -- William Harold Newman <wil...@ai...> We were bedevilled by the daemons of diagrammatic overdesign. My God, three little boxes drawn on the back of a napkin, Game, Frame, and Throw, and it was still too complicated and just plain wrong. -- Robert C. Martin, _Agile Software Development_, p. 72 PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2003-11-04 15:56:38
|
I just received mail from Christophe Rhodes, the expert on cross-compiling CL under CL systems from unrelated codebases, now sojourning in France: > I wonder if you could forward this (or the gist) to the list... I'm not yet > quite fixed up for connectivity (hence reading via gmane's web archive, and > mailing from this e-mail address, which is the only one I can access > without running arbitrary code on a work computer -- probably not the best > idea in one's first week :-). > > The issue with clisp is likely to be the fact that DEFSTRUCT :INCLUDE is > broken under file compilation in clisp-2.31. As you've observed already, > under balky xc hosts, already annoying by their gratuitous non-compliances, > the habit of exiting under an error with an exit code of "success" merely > aggravates the feeling that one wants to take Unix and bash it against a > wall, thereby saving the world a host of pain (except, erm, I'd forgotten > how much I hated Windows until I tried using it for the first time in $n$ > years yesterday :-) > > I posted a clisp patch to sbcl-devel(!) a week or so ago, which is > necessary to make it understand DEFSTRUCT :INCLUDE in the file compiler. I > haven't had any feedback at all from the clisp developers as to whether > it's the right patch, but it let me build to completion. > > As for the LISP_FEATURE_LINUX being defined issue, that gets defined by > genesis-1, so something is going wrong there... is he xcompiling from > Linux, or what? Dunno. I'd advise a sh ./clean.sh anyway, and see if that > problem disappears. :-) (Now that he points it out, I completely agree that the LISP_FEATURE_LINUX *is* quite weird. I simply wasn't paying attention when I skimmed that part of your message before, so when I didn't say anything about it being abnormal, it wasn't because I think it's normal.) -- William Harold Newman <wil...@ai...> We were bedevilled by the daemons of diagrammatic overdesign. My God, three little boxes drawn on the back of a napkin, Game, Frame, and Throw, and it was still too complicated and just plain wrong. -- Robert C. Martin, _Agile Software Development_, p. 72 PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2003-11-13 14:18:22
|
in case anyone ever tries to follow this saga in the mailing list archives... I just received personal mail from Tarjei saying that he's given up on the port and gone back to FreeBSD. He got genesis to run and build a core, but never got the core to run. Apparently, OpenBSD has switched from a.out to ELF since SBCL last ran on it, so somewhat unsurprisingly some of SBCL's loading/linking machinery has rotted now. -- William Harold Newman <wil...@ai...> We were bedevilled by the daemons of diagrammatic overdesign. My God, three little boxes drawn on the back of a napkin, Game, Frame, and Throw, and it was still too complicated and just plain wrong. -- Robert C. Martin, _Agile Software Development_, p. 72 PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |