bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libsigsegv on LinuxFromScratch


From: Bruce Dubbs
Subject: Re: libsigsegv on LinuxFromScratch
Date: Sat, 19 Sep 2020 20:16:08 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 9/19/20 6:47 PM, Bruno Haible wrote:
Thanks Bruce for the details about the .la file.

If ./configure is run with --prefix=/usr with both libsigsegv and
/usr/lib/libc.a are present, configure gives:

configure:10063: checking for libsigsegv
configure:10086: gcc -o conftest -g -O2   conftest.c
/usr/lib/libsigsegv.so /usr/lib/libc.a  >&5
configure:10086: $? = 0
configure:10097: result: yes
configure:10104: checking how to link with libsigsegv
configure:10106: result: /usr/lib/libsigsegv.so /usr/lib/libc.a

Which causes grep to segfault immediately.

Whereas on an Ubuntu 16.04 system the effect is weird in a different sense:
the compilation fails with an error
   /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in 
`/usr/lib/libc.a(strcmp.o)' can not be used when making an executable; 
recompile with -fPIE and relink with -pie
leading to
   checking for libsigsegv... no

If I move all libtool .la files (I really dislike libtool) out of the
way

The .la file contains a comment

   # Please DO NOT delete this file!
   # It is necessary for linking the library.

but in fact all distros I know of don't distribute .la files. Go figure.

The patch below should fix it.


2020-09-19  Bruno Haible  <bruno@clisp.org>

        havelib: Avoid linking with libc.a on GNU systems.
        Reported by Bruce Dubbs <bruce.dubbs@gmail.com> in
        <https://lists.gnu.org/archive/html/grep-devel/2020-09/msg00052.html>.
        * m4/lib-link.m4 (AC_LIB_LINKFLAGS_BODY): When processing the
        dependency_libs value of a .la file, ignore '-lc' options on GNU
        systems.

diff --git a/m4/lib-link.m4 b/m4/lib-link.m4
index eecf70e..5ce1aa2 100644
--- a/m4/lib-link.m4
+++ b/m4/lib-link.m4
@@ -1,4 +1,4 @@
-# lib-link.m4 serial 31
+# lib-link.m4 serial 32
  dnl Copyright (C) 2001-2020 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
@@ -631,7 +631,20 @@ AC_DEFUN([AC_LIB_LINKFLAGS_BODY],
                      ;;
                    -l*)
                      dnl Handle this in the next round.
-                    names_next_round="$names_next_round "`echo "X$dep" | sed 
-e 's/^X-l//'`
+                    dnl But on GNU systems, ignore -lc options, because
+                    dnl   - linking with libc is the default anyway,
+                    dnl   - linking with libc.a may produce an error
+                    dnl     "/usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' 
with pointer equality in `/usr/lib/libc.a(strcmp.o)' can not be used when making an 
executable; recompile with -fPIE and relink with -pie"
+                    dnl     or may produce an executable that always crashes, 
see
+                    dnl     
<https://lists.gnu.org/archive/html/grep-devel/2020-09/msg00052.html>.
+                    dep=`echo "X$dep" | sed -e 's/^X-l//'`
+                    if test "X$dep" != Xc \
+                       || case $host_os in
+                            linux* | gnu* | k*bsd*-gnu) false ;;
+                            *)                          true ;;
+                          esac; then
+                      names_next_round="$names_next_round $dep"
+                    fi
                      ;;
                    *.la)
                      dnl Handle this in the next round. Throw away the .la's


Wow.  I'm glad you found where to fix the problem.  Thanks.

I know some systems need libtool, but Linux tools can find what they need without it. In some cases .la file are embedded in pkgconfig files and removing the .la files sometimes needs fixup.

Just part of the joys of building from source.

  -- Bruce




reply via email to

[Prev in Thread] Current Thread [Next in Thread]