sbcl-devel

I absent-mindedly replied directly to Juho Snellman instead of
to the list; I've enclosed the original message below.
Juho also replied to me, pointing out the not-to-the-list-ness of my
reply and also saying that the libc personality() wrapper predates the
#<sys/personality.h> file and saying that my fix isn't ugly enough to
worry about refixing it before 0.9.5.
----- Forwarded message from William Harold Newman <william.newman@...> -----
Envelope-to: newman@...
From: William Harold Newman <william.newman@...>
To: Juho Snellman <jsnell@...>
Subject: Re: [Sbcl-devel] Re: [Sbcl-commits] CVS: sbcl/src/runtime linux-os.c,1.48,1.49
On Thu, Sep 22, 2005 at 12:14:00PM +0300, Juho Snellman wrote:
> On 9/21/05, William Harold Newman <wnewman@...> wrote:
> > 0.9.4.84:
> > suppressed <sys/personality.h> stuff for old Linux systems (like
> > one of mine) which don't have it
>
> This seems unneccessarily complex and is (as noted in the comments in the
> patch) not the right thing to do in any case. Since <sys/personality.h> is only
> included for the function prototype of personality(), it' d probably
> be cleaner all
> around to:
> * Revert this patch
> * Remove the offending #include
> * Either add a "int personality(unsigned long)" prototype to
> linux-os.c or do the
> system call directly with syscall() as we do with futexes.
The syscall() solution does sound like an improvement over what I did.
If I had realized it was possible, it might even have occurred to me.
In early 0.9.5 I might learn from the futex code how to do it and
commit an improved patch, or at least I can write your proposal into
the comments. It does sound as though it could be simple when done
right; if so, and if someone wants to commit it right now, that's OK
with me too.
I don't see how a hand-coded "int personality(unsigned long)"
prototype would solve the problem. It would allow the personality()
call to be compiled to an object file, but then I would expect the
runtime to fail to link (on the same pre-personality Linux systems
which cause the failure that I was trying to fix).
--
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph
----- End forwarded message -----
--
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph

William Harold Newman wrote:
> I absent-mindedly replied directly to Juho Snellman instead of
> to the list; I've enclosed the original message below.
>
> Juho also replied to me, pointing out the not-to-the-list-ness of my
> reply and also saying that the libc personality() wrapper predates the
> #<sys/personality.h> file and saying that my fix isn't ugly enough to
> worry about refixing it before 0.9.5.
I'm not sure how much of a concern this is but my Fedora Core 3 & 4
systems seem to have /usr/include/linux/version.h from kernel 2.4.20,
probably the version with which glibc was compiled, not the running
kernel version, causing the kernel version check to fail.
If I explicitly define PERSONALITY_SUPPORTED_AT_COMPILE_TIME the
resulting sbcl seems to work just fine.
- Dave

On Fri, 23 Sep 2005, Dave wrote:
> I'm not sure how much of a concern this is but my Fedora Core 3 & 4
> systems seem to have /usr/include/linux/version.h from kernel 2.4.20,
> probably the version with which glibc was compiled, not the running
> kernel version, causing the kernel version check to fail.
Perhaps there should be a tools-for-build/personality-supported-test.c
along the lines of os-provides-dlopen &co?
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."

On Fri, Sep 23, 2005 at 03:30:43PM -0400, Dave wrote:
> I'm not sure how much of a concern this is but my Fedora Core 3 & 4
> systems seem to have /usr/include/linux/version.h from kernel 2.4.20,
> probably the version with which glibc was compiled, not the running
> kernel version, causing the kernel version check to fail.
Thanks for the report, I think we'd prefer releasing something that
actually compiles on most systems. This might be just hubris, but I
believe 0.9.4.85 should compile and run on both old and modern Linux
systems. If there are still problems on older systems, the attached
patch might work better.
--
Juho Snellman

Juho Snellman <jsnell@...> writes:
> Thanks for the report, I think we'd prefer releasing something that
> actually compiles on most systems. This might be just hubris, but I
> believe 0.9.4.85 should compile and run on both old and modern Linux
> systems. If there are still problems on older systems, the attached
> patch might work better.
Just to reassure you a little: the Sourceforge Alpha, running Woody
(Linux kernel 2.2, GNU libc 2.2.5) builds sbcl-0.9.4.85 successfully.
Cheers,
Christophe

Juho Snellman wrote:
> On Fri, Sep 23, 2005 at 03:30:43PM -0400, Dave wrote:
>
>>I'm not sure how much of a concern this is but my Fedora Core 3 & 4
>>systems seem to have /usr/include/linux/version.h from kernel 2.4.20,
>>probably the version with which glibc was compiled, not the running
>>kernel version, causing the kernel version check to fail.
>
>
> Thanks for the report, I think we'd prefer releasing something that
> actually compiles on most systems. This might be just hubris, but I
> believe 0.9.4.85 should compile and run on both old and modern Linux
> systems. If there are still problems on older systems, the attached
> patch might work better.
After updating to CVS version 1.50 of linux-os.c sbcl now compiles and
runs on Fedora Core 3 (kernel: 2.6.11-1.27_FC3smp, glibc:2.3.5-0.fc3.1)
with and without this patch.
Thanks!
- Dave