Sam Steingold wrote:
> >> after:
> >> $ grep -i sigsegv config.status
> >> S["LIBSIGSEGV_PREFIX"]=""
> >> S["LTLIBSIGSEGV"]=""
> >> S["LIBSIGSEGV"]=""
> >> S["HAVE_LIBSIGSEGV"]="yes"
> >> D["HAVE_LIBSIGSEGV"]=" 1"
> >> D["HAVE_LIBSIGSEGV"]=" 1"
> >>
> ...
> > $ ls -l /usr/include/sigsegv* /usr/lib*/libsigsegv*
>
>
> 8 -rw-r--r-- 1 root root 5802 Sep 17 2008 /usr/include/sigsegv-x86_64.h
> 4 -rw-r--r-- 1 root root 733 Aug 15 2008 /usr/include/sigsegv.h
> 0 lrwxrwxrwx 1 root root 19 Jun 15 17:35 /usr/lib64/libsigsegv.so
> -> libsigsegv.so.0.0.0*
> 0 lrwxrwxrwx 1 root root 19 Jun 15 17:34 /usr/lib64/libsigsegv.so.0
> -> libsigsegv.so.0.0.0*
> 12 -rwxr-xr-x 1 root root 9440 Sep 17 2008 /usr/lib64/libsigsegv.so.0.0.0*
Hmm. I cannot reproduce. I installed libsigsegv 2.6 as root, with
# ./configure --prefix=/usr --libdir=/usr/lib64 --enable-shared
# make
# make check
# make install
# rm /usr/lib64/libsigsegv.a /usr/lib64/libsigsegv.la
so that I get essentially the same files as you:
# # ls -l /usr/include/sigsegv* /usr/lib*/libsigsegv*
-rw-r--r-- 1 root root 7526 18. Jun 11:13 /usr/include/sigsegv.h
lrwxrwxrwx 1 root root 19 18. Jun 11:13 /usr/lib64/libsigsegv.so ->
libsigsegv.so.0.0.0
lrwxrwxrwx 1 root root 19 18. Jun 11:13 /usr/lib64/libsigsegv.so.0 ->
libsigsegv.so.0.0.0
-rwxr-xr-x 1 root root 44203 18. Jun 11:13 /usr/lib64/libsigsegv.so.0.0.0
Then
$ ./gnulib-tool --create-testdir --dir=/tmp/testdir libsigsegv
$ cd /tmp/testdir
$ ./configure
checking for a BSD-compatible install... /arch/x86-linux/gnu/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /arch/x86-linux/gnu/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for a BSD-compatible install... /arch/x86-linux/gnu/bin/install -c
checking whether make sets $(MAKE)... (cached) yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for ranlib... ranlib
checking for ld used by GCC... /usr/x86_64-suse-linux/bin/ld
checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /arch/x86-linux/gnu/bin/grep
checking for egrep... /arch/x86-linux/gnu/bin/grep -E
checking for libsigsegv... yes
checking how to link with libsigsegv... -lsigsegv
configure: creating ./config.status
config.status: creating Makefile
config.status: creating gllib/Makefile
config.status: creating glm4/Makefile
config.status: creating config.h
config.status: executing depfiles commands
$ grep -i sigsegv config.status
S["LIBSIGSEGV_PREFIX"]=""
S["LTLIBSIGSEGV"]="-lsigsegv"
S["LIBSIGSEGV"]="-lsigsegv"
S["HAVE_LIBSIGSEGV"]="yes"
D["HAVE_LIBSIGSEGV"]=" 1"
I suspect it has something to do with the autoconf infrastructure of your
package. Can you provide a complete tarball of it? (The clisp cvs still has
libsigsegv.m4 serial 3.)
Failing that, you can also add a "set -x" statement to the head of your
configure script and send me that configure script and its execution output
("./configure 2>&1 | tee logfile") by private mail. Private mail is preferred
here because the two files are likely huge.
Bruno
