Raymond Toy wrote:
> *Hannah Schroeter wrote:
>
> >
> > Will there be OpenBSD (x86) binaries some time again?
> >
> Unfortunately, it seems unlikely since it seems none of the main
> developers has an OpenBSD system. We will have to depend on
> volunteers
> to provide that support.
>
> Ray *
I'd be very interested in getting CMUCL to run on OpenBSD 3.5 (x86) in
order to use aserve+webactions.
I have tried to cross-compile the 19a release, but without sucess. I
reached the rebuild-lisp.sh stage and got some compilation errors.
Trying to get over the hurdle, I made the following changes:
in src/lisp/OpenBSD-os.h I added the following definitions:
typedef size_t os_vm_size_t;
#define PROTECTION_VIOLATION_SIGNAL SIGSEGV
#define SIGNAL_STACK_SIZE SIGSTKSZ
#define CONTROL_STACK_END (CONTROL_STACK_START +
CONTROL_STACK_SIZE)
#define SIGNAL_STACK_START CONTROL_STACK_END
in src/lisp/OpenBSD-os.c I replaced this line:
vm_size_t os_vm_page_size;
with this:
size_t os_vm_page_size;
Although I don't really understand what I have done, the compilation
seems to be successful, but now the linker complains of undefined
functions (see attachment). Any advice?
Iso
--
iso
------------------------------------------------------------------------
Posted via http://www.codecomments.com
------------------------------------------------------------------------
>>>>> "iso" == iso <··········@mail.codecomments.com> writes:
iso> Raymond Toy wrote:
>> *Hannah Schroeter wrote:
>>
>> >
>> > Will there be OpenBSD (x86) binaries some time again?
>> >
>> Unfortunately, it seems unlikely since it seems none of the main
>> developers has an OpenBSD system. We will have to depend on
>> volunteers
>> to provide that support.
>>
>> Ray *
iso> I'd be very interested in getting CMUCL to run on OpenBSD 3.5 (x86) in
iso> order to use aserve+webactions.
Great!
[snip]
iso> Although I don't really understand what I have done, the compilation
iso> seems to be successful, but now the linker complains of undefined
iso> functions (see attachment). Any advice?
Yes. First, you'll probably get better responses from the cmucl
mailing list (see www.cons.org/cmucl for pointers), and second,
include the attachment. :-)
CMUCL used to run on OpenBSD, so it should probably still run there
without too much trouble if OpenBSD hasn't changed its internals too
much.
Ray
Hello!
Raymond Toy <···········@ericsson.com> wrote:
>>>>>> "iso" == iso <··········@mail.codecomments.com> writes:
>[... iso's efforts to cross-compile cmucl ...]
>Great!
Me too ;-)
Because sorry, I seem not to be able to keep up some consistent effort
in things not completely required for work right now, for personal
reasons. So I'm glad about others who have interest *and* more consistant
"energy" for that.
Thanks!
>[snip]
> iso> Although I don't really understand what I have done, the compilation
> iso> seems to be successful, but now the linker complains of undefined
> iso> functions (see attachment). Any advice?
>Yes. First, you'll probably get better responses from the cmucl
>mailing list (see www.cons.org/cmucl for pointers), and second,
>include the attachment. :-)
>CMUCL used to run on OpenBSD, so it should probably still run there
>without too much trouble if OpenBSD hasn't changed its internals too
>much.
OpenBSD has switched from a.out to ELF on the x86 (i386) platform,
some time between 3.3 and 3.4. Also, ld.so usually does random mapping
of shared libraries and the memory layout will be a bit uncommon perhaps
(code is mapped low, and data, even from the same shared library or
from the program itself, is mapped high, so OpenBSD can make data space
non-executable by default [though mprotect(2) will of course have the
desired effect, so the Lisp runtime probably has to mprotect those parts
of the heap which contain executable code with PROT_EXEC]).
Perhaps the runtime of cmucl and sbcl ought to be more tolerant about
the exact virtual addresses in future, as randomization techniques like
this get more widespread (see the problems that are told of from Fedora
Linux, too). Other things like ghc manage to do that, for example, they're
less picky of where they can mmap memory for their heap. Or SML/NJ IIRC.
Kind regards,
Hannah.
From: ·········@random-state.net
Subject: Re: please help test the CMUCL 19a prerelease
Date:
Message-ID: <ceolhk$4pq59$1@midnight.cs.hut.fi>
Hannah Schroeter <······@schlund.de> wrote:
> Perhaps the runtime of cmucl and sbcl ought to be more tolerant about
> the exact virtual addresses in future, as randomization techniques like
> this get more widespread (see the problems that are told of from Fedora
A sensible strategy, and one that even has a straightforward
implementation: teach Python (the CMUCL/SBCL compiler) to emit PIC code.
A SMOP, really. ,-)
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."