[Openmcl-devel] Build failure (Linux x86-64)

Jeronimo Pellegrini jpn at aleph0.info
Fri Apr 4 16:16:09 PDT 2008

On Fri, Apr 04, 2008 at 03:22:49PM -0600, Gary Byers wrote:
> I wish that the search button worked in the mail archives ...
> Linux 2.6.23 kernels introduced the notion of a "vdso", which is a special
> type of shared library which (as I understand it) helps other shared libraries
> communicate with the kernel; this vdso ordinarily gets loaded into the
> address space of every process.
> The vdso links itself into the data structures that describe the
> shared libraries in the process's address space.  Some field in one of
> those data structures can be used as either an absolute address or a
> relative offset to some other object's address; "real" Linux shared
> libraries use the field as an absolute address, but (possibly because
> it's loaded via a different mechanism) the vdso uses the field as
> a (negative) offset.
> When the lisp starts up, one of the first things that it does is to
> (re-)initialize its notion of what shared libraries are available.
> It encounters the vdso, misinterprets the negative offset as an absolute
> address, and segfaults.  I'm pretty sure that that's what you're seeing.

Ah, OK. I see the problem.

> This is fixed in CVS/SVN, but the 070722 binaries are getting pretty long
> in the tooth.  (New release soon!  Honest!)
> The general workaround is:
> a) do something to suppress the vdso loading (see below)
> b) run the 070722 image, update from CVS/SVN, build something more current

sysctl didn't find any setting for vdso, so I passed vdso=0 to the kernel.
But then something really strange happened:

$ ./lx86cl64 
-bash: ./lx86cl64: No such file or directory

$ ls -l lx86cl64
-rwxr-xr-x  1 jeronimo jeronimo 606K 2007-07-21 20:24 lx86cl64

$ strace ./lx86cl64 
execve("./lx86cl64", ["./lx86cl64"], [/* 46 vars */]) = -1 ENOENT (No
such file or directory)


Other binaries seem to work fine.


More information about the Openmcl-devel mailing list