[Openmcl-devel] linux 2.6.23
gb at clozure.com
Sat Oct 27 19:05:28 UTC 2007
Sometimes (I didn't know if it was true in your case), a
distribution's package-management system (rpm/apt/emerge/whatever)
installs new libraries when it installs a new kernel.
The point at which things were dying in the backtrace you sent
is groveling around in some data structures that're created
by the dynamic linker; I don't -think- that that stuff is
sensitive to the kernel version, so the theory seemed like
a good one. (Quite possibly wrong, but good.)
I'll try to install 2.6.23 on a laptop here when I get the chance.
if you haven't heard from me in a few days, please nag.
On Sat, 27 Oct 2007, Takehiko Abe wrote:
> Sorry for my slow reply.
>> I saw something that looks very similar when trying to run under a
>> FreeBSD 7.0 prerelease a few weeks ago.
>> In that case, the problem had something to do with library
>> names/version numbers changing; the lisp image remembered that it
>> had been using (for example, I don't remember the exact details)
>> "libc.so.N"; the dynamic linker actually opened "libc.so.N+1", and
>> the function %REVIVE-SHARED-LIBRARIES - which tries to re-open
>> things that had been opened by OPEN-SHARED-LIBRARY before the image
>> was saved - got confused by the presence of the new C library.
> I use (I assume I am using) the same set of libraries with kernel
> 2.6.22 and 2.6.23. Is it still possible that library names a culprit?
> I am going to try older prerelease version of 2.6.23.
> (I am happy with kernel 2.6.22 though I was just curious about the new
More information about the Openmcl-devel