Bug 199525

"clisp --version" insicates that it has beed built with debugging symbols.
this is because clisp configure now respects the environment variable CFLAGS
and when it is not set uses "-g -O2" as per GNU standards.
please re-configure CLISP with CFLAGS="":
CFLAGS="" ./configure ....
thanks.

AFAIK, clisp is linked dynamically against libsigsegv, so unless there were abi
changes (and/or header differences), a rebuild shouldn't be (absolutely) necessary.

(In reply to comment #1)
> "clisp --version" insicates that it has beed built with debugging symbols.
> this is because clisp configure now respects the environment variable CFLAGS
> and when it is not set uses "-g -O2" as per GNU standards.
> please re-configure CLISP with CFLAGS="":
> CFLAGS="" ./configure ....
> thanks.
Currently CFLAGS is not set at all in the .spec file.
Could you explain, why unsetting CFLAGS is necessary?

(In reply to comment #2)
> AFAIK, clisp is linked dynamically against libsigsegv, so unless there were abi
> changes (and/or header differences), a rebuild shouldn't be (absolutely)
necessary.

clisp is not linked dynamically against libsigsegv.
it is linked statically.
the currently distributed clisp segfaults on
(defun f () (f))
(f)
even when the system is upgraded to libsigsegv 2.4.
when clisp is built against libsigsegv 2.4, I get
*** - Program stack overflow. RESET
instead of segfault.

(In reply to comment #3)
> (In reply to comment #1)
> > "clisp --version" insicates that it has beed built with debugging symbols.
> > this is because clisp configure now respects the environment variable CFLAGS
> > and when it is not set uses "-g -O2" as per GNU standards.
> > please re-configure CLISP with CFLAGS="":
> > CFLAGS="" ./configure ....
> > thanks.
> Currently CFLAGS is not set at all in the .spec file.
> Could you explain, why unsetting CFLAGS is necessary?

when CFLAGS is not set, AC_PROG_CC in autoconf sets it to "-g -O2"
which is not what we want here.
you must NOT unset CFLAGS,
you must SET it to "" (an empty string)
like you do for every other gnu package that uses autoconf
and which you do not want to distribute with the debug symbols.

(In reply to comment #4)
> (In reply to comment #2)
> > AFAIK, clisp is linked dynamically against libsigsegv, so unless there were abi
> > changes (and/or header differences), a rebuild shouldn't be (absolutely)
> necessary.
> 
> clisp is not linked dynamically against libsigsegv.
> it is linked statically.
> the currently distributed clisp segfaults on
> (defun f () (f))
> (f)
> even when the system is upgraded to libsigsegv 2.4.
> when clisp is built against libsigsegv 2.4, I get
> *** - Program stack overflow. RESET
> instead of segfault.

It seems that /usr/bin/clisp is not linked against libsigsegv:

[gemi]:~:$ldd /usr/bin/clisp
        linux-gate.so.1 =>  (0x00ae9000)
        libc.so.6 => /lib/libc.so.6 (0x00b07000)
        /lib/ld-linux.so.2 (0x00aea000)

However /usr/lib/clisp/full/lisp.run is:

[gemi]:~:$ldd /usr/lib/clisp/full/lisp.run
        linux-gate.so.1 =>  (0x00ae9000)
        libm.so.6 => /lib/libm.so.6 (0x00c3c000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00c69000)
        libpq.so.4 => /usr/lib/libpq.so.4 (0x4bd9a000)
        libpcre.so.0 => /lib/libpcre.so.0 (0x06f5d000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x43202000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0x00112000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0x00de3000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x43103000)
        libdb-4.3.so => /usr/lib/libdb-4.3.so (0x0042a000)
        libreadline.so.5 => /usr/lib/libreadline.so.5 (0x0080f000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x0089a000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x06b93000)
        libdl.so.2 => /lib/libdl.so.2 (0x00c63000)
        libsigsegv.so.0 => /usr/lib/libsigsegv.so.0 (0x4b9a4000)
        libc.so.6 => /lib/libc.so.6 (0x00b07000)
        /lib/ld-linux.so.2 (0x00aea000)
        libssl.so.6 => /lib/libssl.so.6 (0x00324000)
        libcrypto.so.6 => /lib/libcrypto.so.6 (0x00149000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00280000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x0012f000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x002f5000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00d7d000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00d93000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00d98000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x003a2000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00144000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00369000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x0011d000)

What does this mean for the libsigsegv?

(In reply to comment #5)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > "clisp --version" insicates that it has beed built with debugging symbols.
> > > this is because clisp configure now respects the environment variable CFLAGS
> > > and when it is not set uses "-g -O2" as per GNU standards.
> > > please re-configure CLISP with CFLAGS="":
> > > CFLAGS="" ./configure ....
> > > thanks.
> > Currently CFLAGS is not set at all in the .spec file.
> > Could you explain, why unsetting CFLAGS is necessary?
> 
> when CFLAGS is not set, AC_PROG_CC in autoconf sets it to "-g -O2"
> which is not what we want here.
> you must NOT unset CFLAGS,
> you must SET it to "" (an empty string)
> like you do for every other gnu package that uses autoconf
> and which you do not want to distribute with the debug symbols.
> 
Could you open a separate bug report on this?

(In reply to comment #6)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > AFAIK, clisp is linked dynamically against libsigsegv, so unless there
were abi
> > > changes (and/or header differences), a rebuild shouldn't be (absolutely)
> > necessary.
> > 
> > clisp is not linked dynamically against libsigsegv.
> > it is linked statically.
> > the currently distributed clisp segfaults on
> > (defun f () (f))
> > (f)
> > even when the system is upgraded to libsigsegv 2.4.
> > when clisp is built against libsigsegv 2.4, I get
> > *** - Program stack overflow. RESET
> > instead of segfault.
> 
> It seems that /usr/bin/clisp is not linked against libsigsegv:
of course, this is just a wrapper that calls lisp.run

> However /usr/lib/clisp/full/lisp.run is:
of course, this is the runtime.

> What does this mean for the libsigsegv?
it means that _EVERY_ update of libsigsegv requires rebuilding of clisp.
Bruno should be able to say more.

(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #3)
> > > (In reply to comment #1)
> > > > "clisp --version" insicates that it has beed built with debugging symbols.
> > > > this is because clisp configure now respects the environment variable CFLAGS
> > > > and when it is not set uses "-g -O2" as per GNU standards.
> > > > please re-configure CLISP with CFLAGS="":
> > > > CFLAGS="" ./configure ....
> > > > thanks.
> > > Currently CFLAGS is not set at all in the .spec file.
> > > Could you explain, why unsetting CFLAGS is necessary?
> > 
> > when CFLAGS is not set, AC_PROG_CC in autoconf sets it to "-g -O2"
> > which is not what we want here.
> > you must NOT unset CFLAGS,
> > you must SET it to "" (an empty string)
> > like you do for every other gnu package that uses autoconf
> > and which you do not want to distribute with the debug symbols.
> > 
> Could you open a separate bug report on this?
> 
bug 199887

I rebuilt clisp locally, and indeed the test case you provided for libsigsegv
now works as expected. This is strange, however. If libsigsegv is linked 
dynamically (as it appears to be according to the ldd output), then it should
not matter, if the library is updated separately. If it does link statically,
then why is there am RPM dependency on the shared library? Also, linking
statically is strongly discouraged. To me it seems, that there is something
wrong here.

One possibility is that the libsigsegv api/abi changed subtly.