From: Scott P. <sR...@sr...> - 2004-04-18 15:44:58
Attachments:
sbcl-openbsd34.diff
|
Attached is a patch which seems to allow (on my computer) SBCL to be boot strapped on OpenBSD 3.4[1] (x86). The boot strapping was done using cmucl on freebsd as the "host". Enjoy! sRp 1| openbsd 3.4 switched from a.out to elf. -- Scott Parish http://srparish.net/ |
From: William H. N. <wil...@ai...> - 2004-04-18 16:23:26
|
On Sun, Apr 18, 2004 at 03:44:56PM +0000, Scott Parish wrote: > Attached is a patch which seems to allow (on my computer) SBCL to be > boot strapped on OpenBSD 3.4[1] (x86). The boot strapping was done using > cmucl on freebsd as the "host". > > Enjoy! > sRp Nifty. As it happens, I'm typing this on an OpenBSD 3.4 machine, and I'll probably install, test, and check in the patch today or tomorrow. (Tomorrow is the day we traditionally freeze the system for monthly releases, so unless there are problems, in a week or so sbcl-release should run on OpenBSD-release, twitchy paranoids happy together again.) -- William Harold Newman <wil...@ai...> <_8jean> I wouldn't mind the nasal daemons, but the brutal warning SBCL prints is annoying. -- <http://tunes.org/~nef/logs/lisp/04.04.10> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Christophe R. <cs...@ca...> - 2004-04-18 17:04:30
|
Scott Parish <sR...@sr...> writes: > Attached is a patch which seems to allow (on my computer) SBCL to be > boot strapped on OpenBSD 3.4[1] (x86). The boot strapping was done using > cmucl on freebsd as the "host". Very cool. Thanks. I wonder if it's possible to support older versions of OpenBSD. Presumably this would be quite hard to do with binary compatibility, what with all the dubious unportable mmap-at-fixed-address stuff that we do, but maybe source compatibility is possible? Is there a way of telling whether a given openbsd system is ELF-based or a.out-based? (I suppose another question that would need to be asked is whether there is someone out there with either a need or a willingness to test on older OpenBSD...) Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Scott P. <sR...@sr...> - 2004-04-18 17:59:36
|
On Sun, Apr 18, 2004 at 06:01:58PM +0100, Christophe Rhodes wrote: > Is there a way of telling whether a given openbsd system is ELF-based > or a.out-based? IDK, but i can look into this. > (I suppose another question that would need to be asked is whether > there is someone out there with either a need or a willingness to test > on older OpenBSD...) I have an old obsd 3.3 box sitting around that i can test on. sRp -- Scott Parish http://srparish.net/ |
From: William H. N. <wil...@ai...> - 2004-04-18 18:55:11
|
On Sun, Apr 18, 2004 at 06:01:58PM +0100, Christophe Rhodes wrote: > Scott Parish <sR...@sr...> writes: > > > Attached is a patch which seems to allow (on my computer) SBCL to be > > boot strapped on OpenBSD 3.4[1] (x86). The boot strapping was done using > > cmucl on freebsd as the "host". > > Very cool. Thanks. > > I wonder if it's possible to support older versions of OpenBSD. > Presumably this would be quite hard to do with binary compatibility, > what with all the dubious unportable mmap-at-fixed-address stuff that > we do, but maybe source compatibility is possible? Is there a way of > telling whether a given openbsd system is ELF-based or a.out-based? > (I suppose another question that would need to be asked is whether > there is someone out there with either a need or a willingness to test > on older OpenBSD...) If there's someone out there who is motivated to do the testing and send in clean patches as necessary (once to to set it up, then every year or two when something breaks), then it should be so little work on our end that it'd be a shame not to do it. But pending word from someone out there with the motivation to run older OpenBSD and the (probably rather modest amount of) energy required to keep SBCL running on it, I wouldn't worry about it. -- William Harold Newman <wil...@ai...> "about as much chance as a one-armed blind man in a dark room trying to shove a pound of melted butter into a wild cat's left ear with a red-hot needle" -- Ukridge (P.G. Wodehouse) 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...> - 2004-04-19 12:33:48
|
On Sun, Apr 18, 2004 at 03:44:56PM +0000, Scott Parish wrote: > Attached is a patch which seems to allow (on my computer) SBCL to be > boot strapped on OpenBSD 3.4[1] (x86). The boot strapping was done using > cmucl on freebsd as the "host". > > Enjoy! > sRp OK, it's merged in CVS. Thank you. It's not quite perfect; there are the ulimit hacks described below, and I note also The build seems to have finished successfully, including 9 (out of 13 ) contributed modules. But it's smart enough to build itself, which is considerably better than not being buildable for OpenBSD at all. The just-merged NetBSD patch collided with your in several places, so I had to fiddle with it manually a little, so there's a possibility I could've done something dumb. But it does build and run on my machine, so I hope it can't be too dumb. Also I wasn't able to figure out how to get "ulimit -d" above 1048576 on my machine, even with :datasize=infinity: in /etc/login.conf. (My machine has about 1400Mbytes RAM+swap; maybe there's some kind of conservatism built into the system? I didn't find it either in the online docs or Google, though.) As a quick fix, which should be suitable for sbcl-0.8.10, I shrank the memory map; later maybe we can do something more ambitious. PS: For when people ask what to do when SBCL's policy of slurping up a lot of address space at startup fights with OpenBSD's ulimits, I sympathize, and here, recorded for posterity, is what I have figured out so far: * Your default soft limit (as reported by "ulimit -a") is probably 64Mbytes. SBCL is too much of a pig for that, and you'd almost certainly have problems at least when you're trying to use it to compile itself, so raise it. (with "ulimit -d") Now, how far can you raise it? ** Ideally, you can get root to set you up with :datasize=infinity: in /etc/login.conf. Then you can raise it to some arbitrary value that I haven't been able to find documented anywhere. (1048576 on my machine) ** If you can't get root to help you out, you're not going to be able to raise it above the hard limit fixed in /etc/login.conf, which in OpenBSD 3.4 seems to default to 256Mbytes. That's enough that it might be reasonable to run SBCL in it, but you'd have to patch the memory map in src/compiler/x86/parms.lisp. -- William Harold Newman <wil...@ai...> Cross-compiling SBCL is easy -- <http://sbcl-internals.cliki.net/Build> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Scott P. <sR...@sr...> - 2004-04-19 14:54:25
|
I decided to upgrade my box to -current (3.5). The result was not pretty as far as sbcl goes; i've yet to figure out what the problem is though. Also haven't been able to find anything in the changelog that would suggest what they might have changed to trigger the symptoms i'm seeing. sRp -- Scott Parish http://srparish.net/ |
From: Scott P. <sR...@sr...> - 2004-04-21 14:25:31
|
On Mon, Apr 19, 2004 at 02:54:23PM +0000, Scott Parish wrote: > I decided to upgrade my box to -current (3.5). The result was not > pretty as far as sbcl goes; i've yet to figure out what the problem is > though. Also haven't been able to find anything in the changelog that > would suggest what they might have changed to trigger the symptoms i'm > seeing. The following spaces seem to work fine with 3.5, and if my memory is correct it should also still work with 3.4: (progn ;;; these ranges seem to work with mmap MAP_FIXED: ;;; obsd 3.4: #x40000000 -- ~ #x78000000; #x80000000 -- ~ #xb8000000 ;;; obsd 3.5: #x40000000 -- ~ #x88000000; #x90000000 -- ~ #xc8000000 ;;; (def!constant read-only-space-start #x40000000) (def!constant read-only-space-end #x47fff000) (def!constant static-space-start #x48000000) (def!constant static-space-end #x57fff000) (def!constant dynamic-space-start #x58000000) (def!constant dynamic-space-end #x77fff000)) Regarding the troubles i was having, it turns out to be a bad idea to use addresses (especially for the static-space) with the high bit set, as index computations can end up being negative. (see the #lisp logs involving the nick "uniq_". (although ignore his insistence on "mquery", as it is flawed for use in this setting.)) sRp -- Scott Parish http://srparish.net/ |
From: Scott P. <sR...@sr...> - 2004-04-19 15:12:07
|
On Mon, Apr 19, 2004 at 07:30:49AM -0500, William Harold Newman wrote: > Also I wasn't able to figure out how to get "ulimit -d" above 1048576 > on my machine, even with :datasize=infinity: in /etc/login.conf. > (My machine has about 1400Mbytes RAM+swap; maybe there's some kind > of conservatism built into the system? I didn't find it either in > the online docs or Google, though.) As a quick fix, which should be > suitable for sbcl-0.8.10, I shrank the memory map; later maybe we can > do something more ambitious. My system has 512mb + 2g swap. Here's what i have in my login.conf for my login account: srp:\ :datasize-max=4096M:\ :datasize-cur=2048M:\ :memoryuse=1024M:\ :stacksize-cur=64M:\ :maxproc-max=1024:\ :maxproc-cur=512:\ :openfiles-cur=256: Having said that, its probably best if sbcl will work by default without forcing users to edit their login.conf. sRp -- Scott Parish http://srparish.net/ |