[Openmcl-devel] 1.11 release

[Anton Vodonosov]

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.

Best regards,
- Anton