[Openmcl-devel] 1.11 release
avodonosov at yandex.ru
Sat Nov 7 14:59:14 PST 2015
08.11.2015, 01:35, "R. Matthew Emerson" <rme at clozure.com>:
>> 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.
I can't comment about the security related decision, moreover I learned already how to rebuild kernel, and it's not the first release I do that.
I just decided to inform you about the fact you probably didn't know.
BTW, another option is static linking with your glibc; a larger binary but with the latest fixes while starts on old platforms too.
More information about the Openmcl-devel