From: Christophe R. <cs...@ca...> - 2002-03-24 01:32:07
Attachments:
sbcl.solaris.diff
sbcl.solaris.files.tar.gz
|
Attached is (I hope) the necessary information required for those enthusiasts who want to play with SBCL on Solaris. Firstly, a patch against current CVS, which fixes existing code for solaris and also removes some non-shisms from the tests and GNU findisms from clean.sh; secondly, the extra files newly referenced. It probably is still necessary to build using bash rather than sh, but the fix if necessary is to find lines of the form export FOO='bar baz' and change to FOO='bar baz' export FOO So. As ever with these patches, there are issues. Possibly the most pressing is "what to call this OS that I've ported SBCL to?" uname and most of the cmucl-derived code seem to want to call it SunOS; on the other hand, in the cmucl lisp/ directory there's solaris-os.c as well as sunos-os.c. As well as this confusion, the C runtime depends on having the SVR4 macro defined (sigh). Comments on this welcome. Apart from this, it's worth checking the various bits of the patch; they're not terribly invasive, but doubtless better ways of doing things are possible; also, I have absolutely no idea what the sigsetmask stuff is doing :-( Oh, well. On the plus side, my solaris build seems to pass as many tests as the linux one did (all but irrat.lisp), though I did have to run the foreign one by hand. Oh, yes -- I've only tested this build process with GNU cc, as and ld -- it would surprise me quite a lot if it worked flawlessly first time with the Sun toolchain. Let me know, though :) Enjoy, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: Christophe R. <cs...@ca...> - 2002-03-25 18:35:05
|
On Sun, Mar 24, 2002 at 01:31:41AM +0000, Christophe Rhodes wrote: > Attached is (I hope) the necessary information required for those > enthusiasts who want to play with SBCL on Solaris. Firstly, a patch > against current CVS, which fixes existing code for solaris and also > removes some non-shisms from the tests and GNU findisms from clean.sh; > secondly, the extra files newly referenced. I have now merged the SunOS (aka solaris) support into 0.7.2.1; the CVS log message erroneously claims to be for 0.7.1.1, but version.lisp-expr is right. I would appreciate it if someone else could test the building, as though I think I have caught the bash/kshisms, I could easily have missed some. Apart from that, everything should be straightforward, except that I don't have a *BSD system to test the new constants that are grovelled from system headers (WUNTRACED and WNOHANG) -- I hope that they get picked up. I haven't noticed any difference by conditionally commenting out the call to sigsetmask in the toplevel code, but then I haven't played extensively with the system -- just checked that the tests run (and that multiplication works). Feedback is welcome -- I hope it works :-) Cheers, Christophe |
From: Nathan F. <fr...@ro...> - 2002-03-25 21:59:03
|
On Sat, 2002-03-23 at 20:31, Christophe Rhodes wrote: > Oh, well. On the plus side, my solaris build seems to pass as many tests > as the linux one did (all but irrat.lisp), though I did have to run the > foreign one by hand. Oh, yes -- I've only tested this build process with > GNU cc, as and ld -- it would surprise me quite a lot if it worked > flawlessly first time with the Sun toolchain. Let me know, though :) I can confirm that the Sun toolchain is not effective in compiling the runtime. :) I am also curious why the build instructions on sbcl-internals suggest running make-config.sh on the host, when in the very next step the target's local-target-features.lisp-expr is copied over. Most peculiar... I will report back my findings once I get the GNU toolchain installed on the Sun machines here. -- Nathan | http://www.rose-hulman.edu/~froydnj/ | Credo ut intelligam From Man's effeminate slackness it begins. --Paradise Lost |
From: Christophe R. <cs...@ca...> - 2002-03-25 22:19:58
|
On Mon, Mar 25, 2002 at 04:43:37PM -0500, Nathan Froyd wrote: > On Sat, 2002-03-23 at 20:31, Christophe Rhodes wrote: > > Oh, well. On the plus side, my solaris build seems to pass as many tests > > as the linux one did (all but irrat.lisp), though I did have to run the > > foreign one by hand. Oh, yes -- I've only tested this build process with > > GNU cc, as and ld -- it would surprise me quite a lot if it worked > > flawlessly first time with the Sun toolchain. Let me know, though :) > > I can confirm that the Sun toolchain is not effective in compiling the > runtime. :) Heh. Ideally, of course, we'd want to support building under the Sun toolchain if that's feasible with not too much pain -- I don't have access to them, though... > I am also curious why the build instructions on sbcl-internals suggest > running make-config.sh on the host, when in the very next step the > target's local-target-features.lisp-expr is copied over. Most > peculiar... make-config also sets up some symlinks for building the lisp cross-compiler (it creates src/assembly/target and src/compiler/target links pointing at the relevant architecture-specific files, as well as creating local-target-features; the local-target-features from the host make-config stage will have the wrong OS feature in it -- this is probably a FIXME :-). > I will report back my findings once I get the GNU toolchain installed on > the Sun machines here. Great, thanks :-) I shall be without connectivity for a week or so over Easter (aah, holidays) -- I'm taking my laptop but I don't expect to get vast amounts of SBCL development done; perhaps the incremental improvement of the type system that I've been thinking about (I know that the proper solution is to rework it in terms of CLOS, but I think that there's value in an interim solution if only because it gives the refactorer something to aim for :-) Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: Nathan F. <fr...@ro...> - 2002-03-26 00:13:09
Attachments:
fixup-preproc.diff
|
On Mon, 2002-03-25 at 17:19, Christophe Rhodes wrote: > On Mon, Mar 25, 2002 at 04:43:37PM -0500, Nathan Froyd wrote: > > I can confirm that the Sun toolchain is not effective in compiling the > > runtime. :) > > Heh. Ideally, of course, we'd want to support building under the Sun > toolchain if that's feasible with not too much pain -- I don't have > access to them, though... I didn't try running things with Sun's cc; I can try that too once I get GNU binutils installed. What version of GCC are you using? There's still lots of compiler warnings going on (complaints about multi-line strings in src/runtime/runtime.c, comparisons between pointers and integers, long int args expected, that sort of thing). My gcc may be trying to compile 64-bit binaries, which might screw things up... Attached is a small patch for a couple of header files that fix obvious errors. > make-config also sets up some symlinks for building the lisp > cross-compiler (it creates src/assembly/target and src/compiler/target > links pointing at the relevant architecture-specific files, as well as > creating local-target-features; the local-target-features from the host > make-config stage will have the wrong OS feature in it -- this is > probably a FIXME :-). This makes sense. I forgot about the symlink hooking up. This might go away once the build system gets reorganized; I think whn said something about taking away the target symlinks and placing fasls in the corresponding directory to their source files in TODO or someplace like that... -- Nathan | http://www.rose-hulman.edu/~froydnj/ | Credo ut intelligam From Man's effeminate slackness it begins. --Paradise Lost |
From: Christophe R. <cs...@ca...> - 2002-03-26 08:54:46
|
On Mon, Mar 25, 2002 at 06:57:35PM -0500, Nathan Froyd wrote: > On Mon, 2002-03-25 at 17:19, Christophe Rhodes wrote: > > On Mon, Mar 25, 2002 at 04:43:37PM -0500, Nathan Froyd wrote: > > > I can confirm that the Sun toolchain is not effective in compiling the > > > runtime. :) > > > > Heh. Ideally, of course, we'd want to support building under the Sun > > toolchain if that's feasible with not too much pain -- I don't have > > access to them, though... > > I didn't try running things with Sun's cc; I can try that too once I get > GNU binutils installed. Sure :) > What version of GCC are you using? There's still lots of compiler > warnings going on (complaints about multi-line strings in > src/runtime/runtime.c This one's odd -- I'm fairly sure I didn't touch runtime.c. It's true that there is a multiline string in there, but I don't see this complaint... I'm using gcc 2.95.3. I think a relevant line is: *cpp_arch_default: -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) (from gcc -dumpspecs) -- a gcc that tries to build 64-bit binaries would have sparc64 rather than sparc in there, I think. > comparisons between pointers and integers, long > int args expected, that sort of thing). Yeah -- all the backends do really horrible stuff with pointers and integers; this one's definitely a FIXME too (it would be nice to have a runtime that compiles without warnings if only so that porters can see what they need to fix). > My gcc may be trying to compile > 64-bit binaries, which might screw things up... That would definitely be a no-no, because of the games we're playing with pointers and integers. > Attached is a small patch for a couple of header files that fix obvious > errors. Thanks very much. My gcc (even with -Wall) doesn't complain about those -- how did you get warnings (or errors) from yours? Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: William H. N. <wil...@ai...> - 2002-03-26 15:31:54
|
On Tue, Mar 26, 2002 at 08:54:19AM +0000, Christophe Rhodes wrote: > On Mon, Mar 25, 2002 at 06:57:35PM -0500, Nathan Froyd wrote: > > What version of GCC are you using? There's still lots of compiler > > warnings going on (complaints about multi-line strings in > > src/runtime/runtime.c > > This one's odd -- I'm fairly sure I didn't touch runtime.c. It's true > that there is a multiline string in there, but I don't see this > complaint... I'm using gcc 2.95.3. I think a relevant line is: > *cpp_arch_default: > -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) > (from gcc -dumpspecs) -- a gcc that tries to build 64-bit binaries would > have sparc64 rather than sparc in there, I think. not that odd... Just a few days ago I had occasion to skim the release/install docs for a >3 version of GCC. I ran across a remark that they now consider their multiline string support to be, misquoting from memory, a poorly specified extension which is now deprecated. They had some suggestions for how to fix old code, one of which I think was replacing the bare ASCII newlines with ASCII backslash, ASCII n, ASCII backslash, ASCII newline. -- William Harold Newman <wil...@ai...> "Now it's a couple of guys sitting in a living room with laptops. (And jeans turn out not to be the last word in informality.)" -- <http://www.paulgraham.com/road.html> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Christophe R. <cs...@ca...> - 2002-03-26 10:13:13
|
On Mon, Mar 25, 2002 at 06:57:35PM -0500, Nathan Froyd wrote: > On Mon, 2002-03-25 at 17:19, Christophe Rhodes wrote: > Attached is a small patch for a couple of header files that fix obvious > errors. Thanks; I've merged this into 0.7.2.2 (getting the log message version number right this time!) Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |