Hi,
Bruno Haible wrote:
Sam Steingold wrote:
I get the following output from
./configure --with-libsigsegv-prefix=/home/sds/src/top CC='gcc -m64' build-O
--with-module=rawsock
on Linux ada 2.6.24-1-sparc64-smp:
INCSIGSEGV=
gl_save_CPPFLAGS=
CPPFLAGS=
checking for libsigsegv... (cached) no, consider installing GNU libsigsegv
even though I do have libsigsegv installed:
$ ls -R /home/sds/src/top
/home/sds/src/top:
total 8
4 include/ 4 lib/
/home/sds/src/top/include:
total 8
8 sigsegv.h
/home/sds/src/top/lib:
total 48
44 libsigsegv.a 4 libsigsegv.la*
On Linux bi-arch systems, such as yours, the 64-bit libraries are searched
for in $prefix/lib64, not in $prefix/lib. You can either
- make a symlink lib64 -> lib in that directory, or
- don't use --with-libsigsegv-prefix and instead set
CPPFLAGS=-I/home/sds/src/top/include
LDFLAGS=-L/home/sds/src/top/lib
before the configuration.
And on Solaris bi-arch systems, it would be in $prefix/lib/64, not in
$prefix/lib.
I know this is suboptimal. But we have two conflicting conventions here:
- Your system is built with the convention that 64-bit libraries go in
$prefix/lib64,
- Your libsigsegv installation is built with the convention that all
libraries go in $prefix/lib. These are the GNU defaults.
The only reasonable solution I can see would be that the GNU defaults get
changed to match the convention on the particular platform.
so this boils down to a bug in libsigsegv (coming from autconf):
make install should install it in lib64, not lib, right?
