GNU bug report logs - #50098
Configuring --with-libsigsegv results in link error

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50098 in the body.
You can then email your comments to 50098 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Evan Miller <emmiller <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: Configuring --with-libsigsegv results in link error
Date: Tue, 17 Aug 2021 14:06:09 -0400

Using grep 3.7 (as well as master), I'm seeing undefined symbol errors after pointing the build to use a local installation of libsigsegv (version 2.13).

Making all in src
  CCLD     grep
Undefined symbols:
  "_stackoverflow_install_handler", referenced from:
      _c_stack_action in libgreputils.a(c-stack.o)
  "_sigsegv_install_handler", referenced from:
      _c_stack_action in libgreputils.a(c-stack.o)
ld: symbol(s) not found


Configure appears to find the library (which is provided by MacPorts) correctly. The config.log contains:

LIBSIGSEGV='-L/opt/local/lib -lsigsegv'


Compiler

powerpc-apple-darwin8-gcc-apple-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16)


System

8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc


It's an older system but seems close to building the program. Let me know what additional information would be useful for debugging.

Evan

Message #10 received at 50098-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Evan Miller <emmiller <at> gmail.com>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 50098-done <at> debbugs.gnu.org
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Tue, 17 Aug 2021 12:12:17 -0700

[Message part 1 (text/plain, inline)]

On 8/17/21 11:06 AM, Evan Miller wrote:
> Using grep 3.7 (as well as master), I'm seeing undefined symbol errors after pointing the build to use a local installation of libsigsegv (version 2.13).

Thanks for reporting that. It's a bug in Gnulib's c-stack module, which 
I fixed in Gnulib by installing the attached. The problem should be 
fixed in the next Grep release. In the meantime you should be able work 
around the Grep problem by not using --with-libsigsegv.

[0001-c-stack-fix-libsigsegv-dependency.patch (text/x-patch, attachment)]

Message #13 received at 50098-done <at> debbugs.gnu.org (full text, mbox):

From: Evan Miller <emmiller <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 50098-done <at> debbugs.gnu.org
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Tue, 17 Aug 2021 16:02:54 -0400

> On Aug 17, 2021, at 15:12, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> 
> On 8/17/21 11:06 AM, Evan Miller wrote:
>> Using grep 3.7 (as well as master), I'm seeing undefined symbol errors after pointing the build to use a local installation of libsigsegv (version 2.13).
> 
> Thanks for reporting that. It's a bug in Gnulib's c-stack module, which I fixed in Gnulib by installing the attached. The problem should be fixed in the next Grep release. In the meantime you should be able work around the Grep problem by not using --with-libsigsegv.
> <0001-c-stack-fix-libsigsegv-dependency.patch>

Thanks for the patch. At present, the non-libsigsegv implementation does not compile on this machine for reasons described in

https://trac.macports.org/ticket/63381

Message #16 received at 50098 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Evan Miller <emmiller <at> gmail.com>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 50098 <at> debbugs.gnu.org
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Tue, 17 Aug 2021 15:53:08 -0700

On 8/17/21 1:02 PM, Evan Miller wrote:

> Thanks for the patch. At present, the non-libsigsegv implementation does not compile on this machine for reasons described in
> 
> https://trac.macports.org/ticket/63381

Oh, I see you're building for an old system (Mac OSX 10.4.11, circa 
2007) that Apple itself is no longer supporting. Although we don't 
normally worry about such platforms, perhaps you can come up with a 
patch that clearly won't break mainline platforms.

In the meantime I suppose you can try the c-stack patch I just sent you, 
though this will require running autoconf. Alternatively you may be able 
to work around the problem by using something like this:

./configure LDFLAGS='-L/opt/local/lib' LIBS='-lsigsegv'

Message #19 received at 50098 <at> debbugs.gnu.org (full text, mbox):

From: Evan Miller <emmiller <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 50098 <at> debbugs.gnu.org
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Tue, 17 Aug 2021 22:04:43 -0400

> On Aug 17, 2021, at 18:53, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> 
> On 8/17/21 1:02 PM, Evan Miller wrote:
> 
>> Thanks for the patch. At present, the non-libsigsegv implementation does not compile on this machine for reasons described in
>> https://trac.macports.org/ticket/63381
> 
> Oh, I see you're building for an old system (Mac OSX 10.4.11, circa 2007) that Apple itself is no longer supporting. Although we don't normally worry about such platforms, perhaps you can come up with a patch that clearly won't break mainline platforms.

A simple regex substitution (removing double underscores from the struct member names on the affected platform) seems to do the trick in the downstream package. If I have the time and cleverness I'll see about a proper patch.

> 
> In the meantime I suppose you can try the c-stack patch I just sent you, though this will require running autoconf. Alternatively you may be able to work around the problem by using something like this:
> 
> ./configure LDFLAGS='-L/opt/local/lib' LIBS='-lsigsegv'


That workaround is what I was looking for, and will let MacPorts fix its package without waiting for a new Grep release.

Message #22 received at 50098 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Evan Miller <emmiller <at> gmail.com>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 50098 <at> debbugs.gnu.org
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Wed, 18 Aug 2021 07:54:16 -0700

On 8/17/21 7:04 PM, Evan Miller wrote:

>> ./configure LDFLAGS='-L/opt/local/lib' LIBS='-lsigsegv'
> 
> 
> That workaround is what I was looking for, and will let MacPorts fix its package without waiting for a new Grep release.

Thanks. I'm closing the grep bug report as we have a c-stack fix 
installed, which should suffice for the grep case that prompted the bug 
report.

The Gnulib sigsegv module issue is lower priority and can be dealt with 
separately on the bug-gnulib mailing list, if it's dealt with at all.

Message #25 received at 50098-done <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: 50098-done <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-gnulib <at> gnu.org, Evan Miller <emmiller <at> gmail.com>
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Sun, 22 Aug 2021 01:37:00 +0200

Paul Eggert wrote:
> > Using grep 3.7 (as well as master), I'm seeing undefined symbol errors after pointing the build to use a local installation of libsigsegv (version 2.13).
> 
> Thanks for reporting that. It's a bug in Gnulib's c-stack module, which 
> I fixed in Gnulib by installing the attached.

Thanks. It was my mistake from 2021-05-18; sorry.

This patch refactors the macros a bit, so that the test for libsigsegv is
only performed once, not twice.


--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2021-08-21  Bruno Haible  <bruno <at> clisp.org>
+
+	c-stack: Test for libsigsegv once, not twice.
+	* m4/sigsegv.m4: New file, based on modules/sigsegv.
+	* modules/sigsegv (Files): Add it.
+	(configure.ac): Require gl_SIGSEGV. Test gl_sigsegv_uses_libsigsegv
+	instead of with_libsigsegv and gl_cv_lib_sigsegv.
+	* m4/c-stack.m4 (gl_C_STACK): Likewise.
+
 2021-08-21  Bruno Haible  <bruno <at> clisp.org>
 
 	rawmemchr: Fix use in relocatable-prog-wrapper (regression 2021-08-20).
@@ -23,7 +32,7 @@
 
 2021-08-17  Paul Eggert  <eggert <at> cs.ucla.edu>
 
-	c-stack: fix libsigsegv dependency
+	c-stack: fix libsigsegv dependency (regression 2021-05-18)
 	Problem reported for GNU grep by Evan Miller (Bug#50098).
 	* m4/c-stack.m4 (gl_C_STACK): Call gl_LIBSIGSEGV before
 	testing gl_cv_lib_sigsegv.
diff --git a/m4/c-stack.m4 b/m4/c-stack.m4
index f3de54fad..caf1d2de7 100644
--- a/m4/c-stack.m4
+++ b/m4/c-stack.m4
@@ -7,16 +7,14 @@
 
 # Written by Paul Eggert.
 
-# serial 24
+# serial 25
 
 AC_DEFUN([gl_C_STACK],
 [
   dnl 'c-stack' needs -lsigsegv if and only if the 'sigsegv' module needs it.
-  if test "$with_libsigsegv" = yes; then
-    gl_LIBSIGSEGV
-    if test "$gl_cv_lib_sigsegv" = yes; then
-      AC_SUBST([LIBCSTACK], [$LIBSIGSEGV])
-      AC_SUBST([LTLIBCSTACK], [$LTLIBSIGSEGV])
-    fi
+  AC_REQUIRE([gl_SIGSEGV])
+  if test $gl_sigsegv_uses_libsigsegv = yes; then
+    AC_SUBST([LIBCSTACK], [$LIBSIGSEGV])
+    AC_SUBST([LTLIBCSTACK], [$LTLIBSIGSEGV])
   fi
 ])
diff --git a/m4/sigsegv.m4 b/m4/sigsegv.m4
new file mode 100644
index 000000000..d5d1fc4b1
--- /dev/null
+++ b/m4/sigsegv.m4
@@ -0,0 +1,20 @@
+# sigsegv.m4 serial 1
+dnl Copyright (C) 2021 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+dnl From Bruno Haible.
+
+AC_DEFUN_ONCE([gl_SIGSEGV],
+[
+  AC_ARG_WITH([libsigsegv],
+    [AS_HELP_STRING([--with-libsigsegv],
+       [use the GNU libsigsegv library, when present, instead of the gnulib module 'sigsegv'])])
+  if test "$with_libsigsegv" = yes; then
+    gl_LIBSIGSEGV
+    gl_sigsegv_uses_libsigsegv="$gl_cv_lib_sigsegv"
+  else
+    gl_sigsegv_uses_libsigsegv=no
+  fi
+])
diff --git a/modules/sigsegv b/modules/sigsegv
index 2ef84332d..fdd815c37 100644
--- a/modules/sigsegv
+++ b/modules/sigsegv
@@ -20,6 +20,7 @@ m4/mmap-anon.m4
 m4/sigaltstack.m4
 m4/stack-direction.m4
 m4/libsigsegv.m4
+m4/sigsegv.m4
 
 Depends-on:
 havelib
@@ -28,15 +29,11 @@ stdint
 getpagesize
 
 configure.ac:
-AC_ARG_WITH([libsigsegv],
-  [AS_HELP_STRING([--with-libsigsegv],
-     [use the GNU libsigsegv library, when present, instead of the gnulib module 'sigsegv'])])
-SIGSEGV_H=sigsegv.h
-if test "$with_libsigsegv" = yes; then
-  gl_LIBSIGSEGV
-  if test "$gl_cv_lib_sigsegv" = yes; then
-    SIGSEGV_H=
-  fi
+AC_REQUIRE([gl_SIGSEGV])
+if test $gl_sigsegv_uses_libsigsegv = yes; then
+  SIGSEGV_H=
+else
+  SIGSEGV_H=sigsegv.h
 fi
 AC_SUBST([SIGSEGV_H])
 AM_CONDITIONAL([GL_GENERATE_SIGSEGV_H], [test -n "$SIGSEGV_H"])

Message #28 received at 50098 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Evan Miller <emmiller <at> gmail.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org, 50098 <at> debbugs.gnu.org
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Sun, 22 Aug 2021 01:46:33 +0200

Evan Miller wrote:
> > Oh, I see you're building for an old system (Mac OSX 10.4.11, circa 2007) that Apple itself is no longer supporting. Although we don't normally worry about such platforms, perhaps you can come up with a patch that clearly won't break mainline platforms.
> 
> A simple regex substitution (removing double underscores from the struct member names on the affected platform) seems to do the trick in the downstream package. If I have the time and cleverness I'll see about a proper patch.

When you do this, you also need to run "make check", to see whether the unit
tests pass.

Background: On macOS, libsigsegv uses an approach based on the Mach API,
that works also with older macOS releases. Whereas the 'sigsegv' module
uses the POSIX API (sigaltstack() etc.) that was added in newer macOS
versions. IIRC, the 'sigsegv' module has been tested on macOS >= 10.5;
it was *not* tested on macOS 10.4. It is well possible that it does not
work on macOS 10.4. In this case, if you want binaries that work on ALL
macOS releases >= 10.4, use the libsigsegv library and the --with-libsigsegv
configure option, and Paul's fix. A "./configure; make; make check" of a
gnulib testdir will tell you. Run these commands:

  ./gnulib-tool --create-testdir --dir=testdir1 --single-configure c-stack
  cd testdir1
  ./configure
  make
  make check

If they fail, then you do need the libsigsegv library.

Bruno

Message #31 received at 50098 <at> debbugs.gnu.org (full text, mbox):

From: Evan Miller <emmiller <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org, 50098 <at> debbugs.gnu.org
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Sun, 22 Aug 2021 07:19:59 -0400

> On Aug 21, 2021, at 19:46, Bruno Haible <bruno <at> clisp.org> wrote:
> 
>  Run these commands:
> 
>  ./gnulib-tool --create-testdir --dir=testdir1 --single-configure c-stack
>  cd testdir1
>  ./configure
>  make
>  make check
> 
> If they fail, then you do need the libsigsegv library.

FWIW the first step fails produces a warning:

executing aclocal -I glm4
executing autoconf
executing autoheader
executing touch config.h.in
executing automake --add-missing --copy
configure.ac:8: installing 'build-aux/compile'
configure.ac:4: installing 'build-aux/install-sh'
configure.ac:4: installing 'build-aux/missing'
gllib/Makefile.am: installing 'build-aux/depcomp'
parallel-tests: installing 'build-aux/test-driver'
patching file build-aux/test-driver
Hunk #1 FAILED at 109.
1 out of 1 hunk FAILED -- saving rejects to file build-aux/test-driver.rej
patching file build-aux/test-driver


Powering through, "make" emits an undeclared function warning:

gcc-mp-7 -DHAVE_CONFIG_H -I. -I..  -DGNULIB_STRICT_CHECKING=1   -g -O2 -MT c-stack.o -MD -MP -MF .deps/c-stack.Tpo -c -o c-stack.o c-stack.c
c-stack.c: In function 'die':
c-stack.c:106:17: warning: implicit declaration of function 'mempcpy' [-Wimplicit-function-declaration]
       char *p = mempcpy (buf, progname, prognamelen);
                 ^~~~~~~
c-stack.c:106:17: warning: incompatible implicit declaration of built-in function 'mempcpy'


Then ends with an unresolved symbol error:

gcc-mp-7  -Wno-error -g -O2   -o test-c-stack test-c-stack.o libtests.a ../gllib/libgnu.a libtests.a ../gllib/libgnu.a libtests.a
Undefined symbols:
  "_mempcpy", referenced from:
      _die in libgnu.a(c-stack.o)
      _die in libgnu.a(c-stack.o)
ld: symbol(s) not found


I will note that "sigaltstack" is available on 10.4 so perhaps there is hope once the undeclared function is sorted out.

Evan

Message #34 received at 50098 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Evan Miller <emmiller <at> gmail.com>
Cc: Bruno Haible <bruno <at> clisp.org>, bug-gnulib <at> gnu.org, 50098 <at> debbugs.gnu.org
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Sun, 22 Aug 2021 13:42:44 -0700

[Message part 1 (text/plain, inline)]

On 8/22/21 4:19 AM, Evan Miller wrote:
> c-stack.c: In function 'die':
> c-stack.c:106:17: warning: implicit declaration of function 'mempcpy' [-Wimplicit-function-declaration]
>         char *p = mempcpy (buf, progname, prognamelen);

Evidently some dependencies were missing from the c-stack module. I 
installed the attached patch. Please try the same set of commands again.

[0001-c-stack-depend-on-inttypes-mempcpy.patch (text/x-patch, attachment)]

Message #37 received at 50098 <at> debbugs.gnu.org (full text, mbox):

From: Evan Miller <emmiller <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Bruno Haible <bruno <at> clisp.org>, Gnulib bugs <bug-gnulib <at> gnu.org>,
 50098 <at> debbugs.gnu.org
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Sun, 22 Aug 2021 20:55:03 -0400

> On Aug 22, 2021, at 16:42, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> 
> On 8/22/21 4:19 AM, Evan Miller wrote:
>> c-stack.c: In function 'die':
>> c-stack.c:106:17: warning: implicit declaration of function 'mempcpy' [-Wimplicit-function-declaration]
>>        char *p = mempcpy (buf, progname, prognamelen);
> 
> Evidently some dependencies were missing from the c-stack module. I installed the attached patch. Please try the same set of commands again.
> <0001-c-stack-depend-on-inttypes-mempcpy.patch>

After updating gnulib master, the "make" step now ends with the error:

gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I..  -DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../gllib -I./../gllib   -Wno-error -g -O2 -MT test-pthread.o -MD -MP -MF $depbase.Tpo -c -o test-pthread.o test-pthread.c &&\
mv -f $depbase.Tpo $depbase.Po
test-pthread.c:35: error: ‘PTHREAD_RWLOCK_INITIALIZER’ undeclared here (not in a function)
make[4]: *** [test-pthread.o] Error 1

Same or similar results with GCC4 and GCC7.

Message #40 received at 50098 <at> debbugs.gnu.org (full text, mbox):

From: Evan Miller <emmiller <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>, 50098 <at> debbugs.gnu.org
Subject: Re: bug#50098: Configuring --with-libsigsegv results in link error
Date: Mon, 23 Aug 2021 08:39:33 -0400

[Message part 1 (text/plain, inline)]

> On Aug 17, 2021, at 22:04, Evan Miller <emmiller <at> gmail.com> wrote:
> 
> 
>> On Aug 17, 2021, at 18:53, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>> 
>> On 8/17/21 1:02 PM, Evan Miller wrote:
>> 
>>> Thanks for the patch. At present, the non-libsigsegv implementation does not compile on this machine for reasons described in
>>> https://trac.macports.org/ticket/63381
>> 
>> Oh, I see you're building for an old system (Mac OSX 10.4.11, circa 2007) that Apple itself is no longer supporting. Although we don't normally worry about such platforms, perhaps you can come up with a patch that clearly won't break mainline platforms.
> 
> A simple regex substitution (removing double underscores from the struct member names on the affected platform) seems to do the trick in the downstream package. If I have the time and cleverness I'll see about a proper patch.

Attached is a proposed patch to fix the compilation issue, designed by comparing the 10.4 and 10.5 SDKs. It relies on an implementation detail, but I think it's safe to say that the PowerPC headers are frozen at this point.

I have built it on 10.4. I'll try to find some volunteers on the MacPorts side to test on 10.5.

[gnulib-tiger-mcontext.diff (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.