[Openmcl-devel] linux 2.6.23

[Gary Byers]

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
> kernel.)
>
>
> Thanks,
> T.
>
>