[Openmcl-devel] 1.11 release

[R. Matthew Emerson]

> On Nov 6, 2015, at 9:40 PM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
> 
> 07.11.2015, 05:34, "R. Matthew Emerson" <rme at clozure.com>:
>>>  On Nov 6, 2015, at 9:24 PM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
>>> 
>>>  I needed to rebuild kernel in order to run it on my machine,
>>>  because the release binary requires LIBC version newer than I have.
>>>  Don't know if that's important for you.
>> 
>> Thanks for the note. I built the lisp kernel binary on Ubuntu 12.04.
> 
> More precise info about the situation:
> 
> $ uname -a
> Linux cl-test-grid.cloud.efficito.com 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u5 i686 GNU/Linux
> 
> $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.11/linuxx86/ccl ccl-1.11
> 
> $ ccl-1.11/lx86cl
> ccl-1.11/lx86cl: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ccl-1.11/lx86cl)
> 
> $ cd ccl-1.11/lisp-kernel/linuxx8632/
> $ make
> $ ../../lx86cl
> Welcome to Clozure Common Lisp Version 1.11-r16635  (LinuxX8632)!
> 
> 

$ objdump -p lx86cl
[...]
  required from libc.so.6:
    0x06969191 0x00 17 GLIBC_2.11
    0x09691f73 0x00 15 GLIBC_2.1.3
    0x06969195 0x00 14 GLIBC_2.15
    0x0d696912 0x00 13 GLIBC_2.2
[...]

And further,

$ objdump -T lx86cl | grep 2.15
00000000      DF *UND*	00000000  GLIBC_2.15  __fdelt_chk

This function appears to used in the implementation of the FD_SET &c. macros used with select(2) when a feature called _FORTIFY_SOURCE is enabled, as it is by default on my build system (Ubuntu 12.04).

$ gcc -dM -E - </dev/null | grep FORTIFY
#define _FORTIFY_SOURCE 2

Some Googling reveals that the _FORTIFY_SOURCE feature is meant to enable detection of certain cases of buffer overflows when using susceptible functions like memcpy, strcpy, sprintf, etc.

Perhaps I could safely use -U_FORTIFY_SOURCE when compiling the lisp kernel on my Ubuntu 12.04 system.  (Of course, someone will probably consider that to be security blasphemy.)  If I do that, and if I am interpreting objdump's output correctly, objdump -p shows that GLIBC_2.4 would be the newest glibc required.  While rebuilding the lisp kernel locally is not hugely difficult, it would be nice to avoid the need for that.